LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with value change events

I need to be able to use the value change event to handle sorting and control the properties of a multicolumn listbox. I have a slow loop that runs every 10 seconds and acquires new data if it's available. New data is appended directly to the list box. The event structure handles two events. One to change colors of the text when new data is added and another to sort the contents when a user clicks on the column header. The first event seems to work just fine. It only runs when new data is added. The second event is the problem. It runs every time the loop runs and ties up the user interface so that it does not respond.

What am I doing wrong??

By the way, it seems that whatever I am doing wrong crashes LabVIEW while I am
editing the vi. Probably during a partial compile. LabVIEW crashed twice while I was creating this test vi and I don't normally have trouble with LabVIEW crashing. It has crashed in both the transact.cpp and panel.cpp.

Thanks for any help or guidance you can offer.
0 Kudos
Message 1 of 12
(3,836 Views)
Hi dgw

The value(signaling) property is not a value change. It triggers events when you call it, even if value is the same, so you are triggering the event in every loop.
Basically, there are two solutions:
1: add a shift register and a case and trigger only if value changes.
2. Go into the event, add a case and compare new value/old value to process event.

Hope it helps

Alipio
---------------------------------------------------------
"Qod natura non dat, Salmantica non praestat"
---------------------------------------------------------
Message 2 of 12
(3,836 Views)
I have made a few quick modifications, see attached.

-- The lower loop should probably be a plain loop, since the timing is done by the event structure.
-- You cannot use a shift register in the upper loop if you want the acquired list to remain sorted.

Sorry, I am on vacation in the middle of nowhere and only spend a few minutes on this. There are many improvements possible.
Message 3 of 12
(3,836 Views)
The upper loop is just a quick and dirty way to generate some data. The bottom loop was my problem and your changes there work perfectly.

Using value (signaling) to trigger a value change event doesn't really work like I thought it would and information from NI on this subject is scarce. It seems to me that the value change event should simply trigger when the value changes. Having to use value (signaling) is an extra layer of complexity.

This all works well enough now, but would it be better to register these two events as dynamic events??

Thanks for your help.
0 Kudos
Message 4 of 12
(3,836 Views)
There are only two reasons I believe that would modivate you to dynamically register the events. First, if want to be able to register and unregister them. Is there a point in the program where you would like to ignore these event when they are fired? Next, if you would like to handle the events in a SubVI as opposed to where they are generated.

Unless you want to conditionally handle the events or deal with them somewhere other then where they were called I would just leave them statically registered.
0 Kudos
Message 5 of 12
(3,836 Views)
Hi,

Registering events dynamically can also help when you need several event
structures, that handle the same event. This is not a good idea, but if you
do need it, dynamic events work better.

Regards,

Wiebe.

"NIBOUND" wrote in message
news:5065000000050000005BBA0100-1079395200000@exchange.ni.com...
> There are only two reasons I believe that would modivate you to
> dynamically register the events. First, if want to be able to register
> and unregister them. Is there a point in the program where you would
> like to ignore these event when they are fired? Next, if you would
> like to handle the events in a SubVI as opposed to where they are
> generated.
>
> Unless you want to conditionally handle the events or deal wi
th them
> somewhere other then where they were called I would just leave them
> statically registered.
0 Kudos
Message 6 of 12
(3,836 Views)
I agree, I just assumed there was only one event structure.
0 Kudos
Message 7 of 12
(3,836 Views)
I don't want to ignore these events so they always need to be enabled.

My question about static vs dynamic events is because static events seem to require a front panel object even if its not needed for the UI. Dynamic events can be handled from the block diagram without the need for intermediate indicators or controls.
0 Kudos
Message 8 of 12
(3,836 Views)
Yes so if you create a user event it does not need to linked to a front panel control. Therefore if you are creating a control for only the ability to statically capture the event then yes it would be better just to create a user event and register it dynamically. Is this what you are asking about?
0 Kudos
Message 9 of 12
(3,836 Views)
Yes, that was my question. I am going to change over to dynamic events when I don't need a front panel control.

By the way, all of my problems with LabVIEW crashing disappeared when I got the static event wired as Alipio and altenbach suggested.

Thanks for all your help
0 Kudos
Message 10 of 12
(3,563 Views)