Reference-based Property Nodes Fails Silently

[lukepike]

Hello,

I've been using the Actor Framework for a project recently that allows the user to change the units they are using. So in my Actor Core, right before my main event loop, I create an array of references to all the numeric controls. When the user changes the units, I loop over the references and change the control to the new units. This works great... Sometimes. Occasionally, the controls refuse to update. I did some probing and I know the code is running, but they don't update and no error is thrown. Additionally, I noticed other things not working when this happens, such as User events. The weird thing is that it will go away, especially when LabVIEW is restarted, and everything will work again for a while.

Is there a better way to interact with controls that plays nice with the Actor Framework?

Thank you,

Luke

[David_Staab]

I have equally anecdotal claims to make about AF code making LV misbehave. I have some UIs written in AF, and sometimes while repeatedly launching them for unit testing, certain VI Server calls to orient the panes at (0,0) and set the panel size will simply not execute. No errors, no crashes....they just no-op on their calls and move along. If I restart LV, it goes away for at least the first run but sometimes comes back for the second.

Having been an employee at NI, I know this kind of report is enragingly useless to developers because of its lack of reproduceability, but I figure I should at least chime in to put this kind of behavior on AQ's radar.

[komorbela]

May it have something to do with the fact that the regarding the UI thread the indicators are not updated always, onlyif there are resources? I mean the behaviour of the non-sychronously updated indicators. Read more on it here:

http://digital.ni.com/public.nsf/allkb/7B3E63FBA3714447862565D20069CE5F

It's just a guess, but it's suspicious that it happens only to UI thread related things.

[KuGr]

I am looking for the discussion and will post link shortly, but if it is what I am suspecting, force a recompilation of the VI that has the controls being updated.  It appears that they go stale because of a clone - my guess anyway.  For some reason the VI is not tagged as dirty for an automatic recompilation.  I am still not sure that this does not happen on its own though.

EDIT: Here is the thread I was talking about: https://decibel.ni.com/content/thread/12627?tstart=0.  It is part of the ActorFramework group.  I was unfamiliar with the other link that was supplied.  I will look at that too.

-Kurt

[lukepike]

Thanks for your help, everyone. I'll take a look at these. Does this mean it works in a built application?

Luke

[RMThebert]

There is a front panel indicator / control attribute called "Synchronous Display" that is supposed to make the GUI thread wait until that item has updated - just a thought about something that might be related.

[Q7]

I think not. I have built applications that seemed to function OK in Dev mode but when built the Front Panel fails to initialize properly and thrown an error. If you need me to investigate this more I can, I am not experienced at debugging the .exe though.

I do believe KuGr is on the path...we have seen that force recompiling can solve issues. However, in my example above it could not be fixed without deleting the old project and building a new one.

[AristosQueue (NI)]

a) Does anyone have example code they can share to reproduce this?

b) Are those of you who are in the Beta program still seeing this with LV 2012?

[komorbela]

Did you take a look at the link that Kurt posted? Look at the 17. reply: https://decibel.ni.com/content/thread/12627?start=15&tstart=0

To me it seems to be the same problem. What do you guys think? I hope it's the same as than it will be solved in LV2012

[Q7]

I too think these are all related issues. Please see my post (#24) in the thread komorbela posted. I have seen cases where the built application is not repaired by force recompile indicating all bug(s) may not have been discovered.