LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.

 

Regards,

Marc

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.

 

Regards

Marc

Hello everybody,

 

here are my ideas about expanding the functionality of Event structures:

 

1.) Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.

 

2.) Allow for better handling of the event buffer for fired events of Event structures. I would like to have a feature to list and remove item(s) from the buffer of fired events. Otherwise you have always to write some code to catch events, you d'ont want just to execute or you want to remove, because you just pressed the stop button. This could be realised by new leftside and rightside nodes inside the event structure.

 

3.) It should be possible to configure events to run first (placing the fired event as the next event to execute like the queue function "Enqueue Element At Opposite End"). Or add priority to events.

 

4.) Make it possible to add conditions to events, e.g. only allow event foo, if condition bar is True. I'm not sure, how this should look like. Some static conditions could be "key pressed == a" coupled with "key down" event. Conditions could also be coupled to controls via registering the control reference like dynamic events. If my 1st idea is realized, a condition could also be something like "tcp/ip connection is online". If a condition is not fullfilled, than either nothing happens or there is a leftside node, which indicates the status of the condition. This should be configurable.

 

Regards,

Marc

 NativeLoopWait.png
If unwired it would default to 0, and at least let thread switching occur.  You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default...  Maybe also right-click on it and get to choose between "Wait (ms)" and "Wait until Next ma Multiple"?
  
(PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).

A pop-up that appears when a user hovers over a buffer allocation dot would be very useful.

 

Data to display:

1) size of allocation in bytes

2) expected longevity (freed when vi quits vs. USR)

3) frequency of allocation (once at first run, each loop, etc.)

 

I know some of the data can only be a best guess but whatever additional data we can get

will be an improvement, especially when dealing with large data sets.

 

Thanks.

 

Matt