Please add Front panel Control value set with signaling method

[jj2]

Currently there is a method for setting the control value of another VI via the Control Value Set Method. But there is no set with signaling method which allows control of VI's which react to changes on front panel controls. This makes it hard to automate VI's that are using front panel control events. There is a tedious work around to get references to control on the front panel and then use value signaling method . It would be very useful to just have one additonal method that does the signaling in additon to setting the value of the control.

[X.]

Yes, that's what I meant. I didn't read the thread in any kind of detail, so my apologies for having overlooked that. It would be interesting to hear from NI why they prevent from doing something one way, when it can be done using a harmless workaround. 

[AristosQueue (NI)]

> Programmatically firing a LATCHED BOOLEAN IN AN EVENT STRUCTURE is possible after all, I found out here .

I filed CAR 588538 to fix that. It should not be possible... the event behavior is undefined (which is why you can't do it by any other path). I doubt anyone thought to test the Type Cast hack. It'll be easy to add a mechanical action check at the actual property value assignment and then return an error in that case.

[X.]

What is the rationale from preventing this? Apparently a lot of innocent souls are interested in "emulating" a user press on these controls. Keep in mind that LV was originally developed to allow non-programmers to be able to do some basic coding. Putting obstacles to something which looks rather harmless just for the language purity's sake seems a little over the top... Why not call it a "tolerated hack" or even promote it as a full-fledge method?

[AristosQueue (NI)]

It's not thread safe so it doesn't always work. That isn't my area of the code... I do not know why it doesn't work exactly, all I've heard is that attempting to write True from other mechanisms ends up in some sort of race condition that can result in the value being reset to false even though the FPTerm returns False. It's unreliable and thus is banned.

[donkdonk]

Too bad this won't be possible. But I find a little bit of solace in the fact that it requires experienced NI developers to see why it can't be done.

Still would like NI to have a really good look before banning it. 

[..]Apparently a lot of innocent souls are interested in "emulating" a user press on these controls [..]

Yes indeed, that's exactly what we often do in our research environment, kind of macro thing to "emulate" user interaction with the front panel. Very very handy.

I already changed my template, now I have to go back to the old situation.

[redfrank]

Hi,

is there a way of getting X.'s snippet at the top of this thread to work if you've got tab controls on the front panel and you want to set value (signalling) by reference for a control on one of these tabs? GetControlIndexByName still returns a value for a control on the tab, bt the index returned is much greater than the size of Controls[] returned from the vi front panel (which I believe is only giving me a list of controls which includes the tab control but non of the controls on the tab control).

[X.]

I noticed this problem shortly after posting this rapid example.

I posted a more complete one here.

[donkdonk]

> AristosQueue [..] It'll be easy to add a mechanical action check at the actual property value assignment and then return an error in that case.

Saw this discussion again and wondered:

Is there a way to (also) programmatically check whether a boolean is programmed to fire an event in an event structure?

[dadreamer]

---

@donkdonk wrote:

Too bad this won't be possible.

---

Well, with a bit of a "black magic" hackery it's still possible. You can test on your own with the VI from that thread.

[wiebe@CARYA]

To me "Be warned to not use it in the production, please." means it isn't possible.