update on Undo (Ctrl+Z) project presented at our first meeting

[FabiolaDelaCueva]

Hi all,

First of all, thanks again for attending the first LabVIEW Architects Forum. It was great to see you all there and we will definitely continue to organize these meetings.

I uploaded the code I presented yesterday here:

http://decibel.ni.com/content/docs/DOC-14805

I also confirmed that in the LabVIEW help it says that the menu options for Undo/Redo do not work on stand alone applications built in LabVIEW.

And as suggested yesterday, I posted the idea in the idea exchange: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Undo-Redo-menu-options-available-in-stand-alone/i...

I will work now on my homework of implementing the "Undo Brat VI", but as you mentioned yesterday, you are welcome to work on that as well.

Thanks again,

Fab

[FabiolaDelaCueva]

And for those of you that did not have the opportunity to attend Norm's SMoReS presentation at NI Week and learn about the "Brat VI" we were talking about yesterday, here is a link for that:

http://decibel.ni.com/content/docs/DOC-11996

[FabiolaDelaCueva]

Ok, it was not as straight forward as I expected it. I could not find a property node to find the reference to the parent's menu.  Also, I had to exclude not only indicators, but booleans with latch mechanical action as well.

UndoBrat.vi can be placed in the block diagram of any VI that has a run time menu with "User Item" type menu tags for "Undo" and "Redo" and it would implement this functionality. The only other thing that needs to be added is firing the global stop event.

This VI uses "Tool-GetParent.vi" and "VIG-GlobalStop.vi" presented by Norm Kirchner in his SMoReS presentation at NI Week 2010

I added a 4th folder to the project with the UndoBrat solution here: http://decibel.ni.com/content/docs/DOC-14805

This solution assumes the parent VI already has the Edit menu with the "User Item" type entries for "Undo" and "Redo".

Try it out and let me know if it works for you and any other modifications that we should make to the code.

Thanks to Grant for adding the images to the code posting.

[AristosQueue (NI)]

I sent two further revisions to Fabiola this morning. I've asked her to buddy my changes and post them if they look correct.

[AristosQueue (NI)]

I forgot to update this forum... the updates have been posted.

[FabiolaDelaCueva]

AristosQueue,

I love the changes you made for only keeping track of the control that changed instead of the brute force approach of copying everything. It makes things a lot more efficient, cleaner and easier to understand.

I can not believe that I was looking for a property node to find the parent's menu reference, when all I had to do was to connect the VI reference to the Event registration and look for the "Menu Selection (User)" event!!! Thanks for finding that and cleaning it up.

As you mentioned in the meeting, classes might be an overkill for only undoing the value of a control, but here is an example of how it seemed like an overkill but it opened the possibility for adding other things to undo in the future. Adding the transaction class opens the door to a lot of other possibilities. I can think, for example, in the case of a form there could be a menu option to clear the form. This menu option could be registered as a new transaction and the operation could be undone. Another example of feature creep waiting to happen!

Thanks for taking the time to look into this.

Fab