Why no VALUE CHANGED event?

[CoastalMaineBird]

LV2013, Win7

The attached VI doesn't work the way I expected.  I'm wondering what can be done.

My real program (this is not it) has a window with a menu.  You edit a file of alarm settings in this window.

It uses a menu with NEW, OPEN, REVERT, SAVE, and SAVE AS.

I want to offer a warning: if you change the file on screen, then try to REVERT, or NEW or OPEN, you get a dialog that says the file is 'dirty", i.e., has unsaved changes, and you can cancel, proceed anyway, or save and proceed.

I also want to disable some menu items if the file is dirty.

For the most part it works fine.  But there's an edge case that I can't seem to make work.

If you run this program, change the string, then (as the very next thing) click the FILE MENU, then the menu doesn't register the file as dirty.

Even though I have a "dirty" test right there in MENU ACTIVATION, and it gets run before the menu pops up,  it doesn't register as dirty.

So the menu is wrong, and after you choose an action, the action still sees DIRTY as false.

NOw, if you change the string and then CLICK OFF somewhere, the VALUE CHANGED event happens, and it gets seen as dirty.

But if you take a clean file, type something in and immediatly click the menu (or type ctrl-O) then it's not recognized.

Any ideas how to get around this?

Before you say  to turn on UPDATES VALUE WHILE TYPING, know that it should work on numeric fields too, where there is no such option.

[Hooovahh]

---

@CoastalMaineBird wrote:

LV2013, Win7

Before you say  to turn on UPDATES VALUE WHILE TYPING, know that it should work on numeric fields too, where there is no such option.

---

So glad you put that in there I was going to suggest it.  For numeric controls there is an extra step.  Use the property node Numeric Text >> Text and it will return the text in that control regardless if the value has changed yet or not.  So you can read the value of the control this way and know if the value is different from what you last had determining if the change is dirty or not.

You can try other things like force a key focus off of your control, then re-invoke whatever it was you were doing, but in your case that isn't easy to do since I don't think you can programmatically invoke menu items, unless that changed and I forgot.

EDIT:  It looks like you can invoke a menu using the application invoke node UI >> Invoke Menu Item, but I can't get it to work on a sub menu like File.

Double EDIT:  OR you can replace your numeric controls with string controls, then use update while typing.  Of course then you'd probably need to reimplement lots of stuff the numeric control gives you.

[CoastalMaineBird]

---

@Hooovahh wrote:

---

Use the property node Numeric Text >> Text and it will return the text in that control regardless if the value has changed yet or not.  So you can read the value of the control this way and know if the value is different from what you last had determining if the change is dirty or not.

---

Well, the cluster in the real world is a cluster with an array of clusters, with a string or two, a boolean, and an array of clusters of several numbers.

Do I really have to check the properties of check all those things?  I just want to know if it has changed or not.

[CoastalMaineBird]

you can replace your numeric controls with string controls, then use update while typing.

That's just nasty.

It seems to me that clicking on the menu bar (or typing a menu shortcut key) ought to end editing.

It would trigger the MENU ACTIVATION event.

Even if that occurs before the VALUE CHANGED event, I could put the DIRTY test in the MENU ACTIVATION, and all would be well.

But it doesn't work that way.

[Hooovahh]

Hey it sucks but I came up with like 3 terrible solutions, isn't that more imporant than 0 working solutions?  For my situations in the past I had just one or two rouge controls I needed to account for so I just handled those specially, sorry to hear your data structure is relatively complicated making this difficult.  If you find any other solution I'd be interested in hearing it.

[aputman]

---

It seems to me that clicking on the menu bar (or typing a menu shortcut key) ought to end editing.

It would trigger the MENU ACTIVATION event.

Even if that occurs before the VALUE CHANGED event, I could put the DIRTY test in the MENU ACTIVATION, and all would be well.

But it doesn't work that way.

---

It does end the editing but if you think about it, the system has to see the Menu Activation first, triggering that event, which in turn ends editing and triggers the VALUE CHANGE event.  This came up in another post recently but it was a little different scenario. 

http://forums.ni.com/t5/LabVIEW/LV2013-Events-ordering-mouse-down-vs-value-changed/td-p/3175412

What happens if you do a mouse leave event on the string control to do the DIRTY test?  That way it happens before the MENU ACTIVATION. 

[CoastalMaineBird]

It does end the editing

No, it doesn't.  Try it on my little test program:

Type "12345" into the string field.

Click on the menu bar.

The DIRTY light does not come on.

Hit ESC key to cancel the menu.

The DIRTY light does not come on.

Type "6789".

The DIRTY light does not come on.

the "6789" went right where you left the editing cursor, because editing hasn't ended.

[CoastalMaineBird]

What happens if you do a mouse leave event on the string control to do the DIRTY test? 

--- Nothing different.  Because editing hasn't ended.

That way it happens before the MENU ACTIVATION. 

--- Maybe true, but the string still thinks it's editing.

When I read the control it has the old value, not what's showing.

[CoastalMaineBird]

I came up with like 3 terrible solutions, isn't that more imporant than 0 working solutions?

Indeed.

I didn't mean to sound ungrateful.

Thanks for directing your brain cells toward my problem.

[CoastalMaineBird]

Regardless of the DIRTY test, there's another problem.

My SAVE code doesn't care about dirty or not.

If you change the field and type ABCDEF ^S, the ctrl-S means SAVE and it executes the save code, but the values it saves don't include your last changes, because editing was never ended.