Why no VALUE CHANGED event?

[CoastalMaineBird]

There's another aspect that doesn't work quite right (IMO).

I have an array of clusters showing one element, and I use a separate slider to choose which index is visible.

I have the mouse WHEEL set to change the slider.

If you make changes to something in the visible element, and then mouse over the slider and roll the wheel, the index changes (as it should) without entering the new value.

[dan_u · Accepted solution]

A possible workaround is to remove the KeyFocus from the element that is currently edited. You can also force that by setting the KeyFocus to a dummy control and removing the KeyFocus again (then you don't need to know which control currently had the KeyFocus). This will end the edit and trigger the value change event.

If you do that in the Menu Activation before reading out the controls you will get the updated value (event though the value change event will fire only afterwards).

[CoastalMaineBird]

Yes!

Thanks, dan_u !

That works.  Attached is a test program with a BROKEN / FIXED switch.

The FIXED case simply sets KEYFOCUS on a dummy control (the switch itself) in the MENU ACTIVATION before reading the cluster's value.

That forces an end to editing and the menus work properly, and the shortcuts work properly.

Even ABCDE ^S works properly: the SAVE code sees the ABCDE that you want to save.

The dummy must be a CONTROL (not indicator).

It must be VISIBLE (not hidden).

The downside is you lose the edit cursor where you were.  But that's less painful than losing data.

[CoastalMaineBird]

If the dummy item is a NUMERIC or STRING control, and it's behind something, giving it KEY FOCUS means that the text part of the control (but not the border) shows through whatever you hid it behind.  Yuck.

Best to make it a boolean control, which doesn't try to come in front.

Or just hide the thing outside the window borders.

[CoastalMaineBird]

Can anyone try that ValChg2.vi with LV 2015?

Just set the switch to BROKEN, and run it.  Type ABCDE ^S in the STRING control, and see what the log shows.

Does it show the value as including the ABCDE?

[dan_u]

I'm glad it works. The workaround will not be suited for all cases, e.g. when you update the data in an object inside the value change event you still have the issue that the events fire in the "wrong" order (see this thread: http://forums.ni.com/t5/LabVIEW/LV2013-Events-ordering-mouse-down-vs-value-changed/td-p/3175412), so the data will only be updated after the activation event fires.

Sorry, I only have LV2012.

[Hooovahh]

---

@CoastalMaineBird wrote:

Can anyone try that ValChg2.vi with LV 2015?

Just set the switch to BROKEN, and run it.  Type ABCDE ^S in the STRING control, and see what the log shows.

Does it show the value as including the ABCDE?

---

I tried it in 2015 typing "ABCD ^S" then clicked File in the menu, and the log only has one line.

Menu Activation.  String is "Edit This String", Number is 123.0,  Dirty = FALSE

If you don't like the border on the control, have the focus set to a control that is off the part of the FP that can be seen.

[dan_u]

---

@CoastalMaineBird wrote:

The downside is you lose the edit cursor where you were.  But that's less painful than losing data.

---

You can also set the KeyFocus back to the edited object. Just use the "Find Control with Key Focus" method to get a reference to the control, set the KeyFocus to the dummy control, then back to the control reference returned by the find method.

[CoastalMaineBird]

I tried it in 2015 typing "ABCD ^S" then clicked File in the menu, and the log only has one line.

OK, thanks.  That means that nothing has changed.

[Hooovahh]

---

@CoastalMaineBird wrote:

OK, thanks.  That means that nothing has changed.

---

I doubt NI would see this as a bug, and fixing it would probably mean breaking code that relies on this behavior.  There is a work around and it isn't one of my 3 terrible ones, so I doubt we will see this behavior change.