Thoric

As the code grew I incidentally came across this solution. Not great, and I should make it a typedef, but it's better that it was.

I'm experimenting with this framework, and my early impressions are that it's very powerful and flexible. In my experimentation I created a Messenger Event for registering with a sub-actor Observer registry. In the code I can give the User Event a custom label to make the Event Structure case more understandable (green highlighting in image), but I'm struggling to set a custom label for the Messenger Event, which I store in the actor internal data shift register (Blue highlighting in image). Is there a recommended approach that I'm missing? Applying a typecast always fails.

Darren, Thank you. I have been trying to dynamically launch something into the correct application context to ensure access to the full class (and library) hierarchies, to no avail. This appears to have worked, so I'm very grateful! If you're at the European CLA Summit in Rome this year you will be able to see the fruits of this effort in my presentation (hopefully!).

I'm creating a utlity VI to launch from the Tools menu. When a VI is launched from here it is thrown into the unique NI.LV.Dialog application context. From here, things get tricky, because we can't immediately see the VI from which the menu item was called. If you call: then you get an application instance and a VI name to use in Open VI reference. But that doesn't seem to solve an issue I'm having. In my calling VI (from where Tools > MyUtilityVI was selected) I have front panel control with User Tag information in them. I can get a reference to this VI and use Read User Tag.vi to get to the string data I've embedded in the controls. The string data is actually a LV class flattened to XML. This is where I get a bit confused - in the utility VI I can read the XML string and place an unflatten from XML string function to typecast it back to a LV class. When I debug and run the utility VI in the dev environment (Project application instance) it works fine. But when called from the menu, and in NI.LV.Dialog app instance, I get error 1527 "Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW" This is presumably because some derivative/child of the class is not in memory in the NI.LV.Dialog app instance. So how do I make sure that the entire class hierarchy is available to this application instance? Into the Unflatten XML String function I'm passing an instance of the class parent, but presumable a child or two is missing. Unfortunately the class has dozens of children, and I'm not keen on placing them all into the block diagram to ensure they're accessible to this application instance! Here I read about accessing VIs across contexts, but I don't see a solution. This opens a reference to the VI in the original instance, but the utility VI is still in NI.LV.Dialog instance so cannot access the class hierarchy. Here is a chap attempting to dynamically launch a VI into the application instance of the calling VI, but it fails. According to Stephen this is not possible, LabVIEW prevents it to keep everything in the NI.LV.Dialog context. Ultimately, my LabVIEW Project will become a tool installed into user.lib, with the utility VI in the Tools menu (project folder). It needs access to the VIs that define the toolkit, which currently are in the active Project (because I'm still developing the tool), but ultimately will be found in the user.lib folder. Will it start working once I migrate all the VIs like this?

Totally understand, and completely agree. I've had my presentations recorded before and I think I'd be fine with them on the searchable domain (YouTube), but I know there are others who wouldn't be. Good call.

My need is to clear the "Window move" undo entry, which I'm programmatically doing after loading the vi. Hence I needed to wipe the undo history programmatically too.

Awesome. Next year I'll make more effort to visit the sessions you aren't recording, that way I can get to see more overall. Thanks Mark!

Wish I'd read this thread before I took my CLED! I didn't realise documentation was worth so little! Luckily I passed also, but next time I take a test I'll pay more careful attention to the grading criteria! Well done to everyone who's passed the CLED, and good luck to all future LabVIEWers who take it!

Darin, Awesome. Thank you!

I'm looking for a way to get the color of a datatype wire, i.e. as it would appear in the connector pane for an associated front panel control. A little more detail: Take a standard VI with a handful of controls and indicators wired to the connector pane. Each datatype's core wire color is shown in the associated connector pane terminal box. Can you programmatically retrieve this color for any datatype? What I've tried: I've looked for a "datatype" property node in the hope of extracting further information, but not sure that's helpful. I've played around with the Class Identifier for a control reference, but not sure what use that really is? I've looked for a way to grab an image of the connector pane's terminals to grab the color from the filled rectangles. I can only seem to get the VI icon with the connection text as seen in context help. Any ideas?

Yair, Rolf, Thanks for the replies. I agree, the IDE has always been difficult to tap into, and this was something I wasn't truly expecting to get to work, but it was always worth asking the world's best before giving up. The Fake Exec state isn't going to work for me, the VI has to remain in true edit mode for what I had in mind. Back to the drawing board...

Is there a way to interfere with the edit time shortcut menu of a front panel control? I want to be able to register for the Shortcut Menu Activation? filter event for the controls of a VI that's in edit mode, and inject my own menu items. I can only get this to work if the target VI is reserved for execution (running state), and not when idle. (To be clear, there are two VIs here. A running VI with an event structure that's meant to be interfering with the shortcut menus of the other's front panel controls whilst the operator is editing it. I want to be able to inject my own menu items.)

How bizarre! Yes, that works. Dropping a simple ADD function, then deleting it, vaporizes the Undo History. Any thoughts as to why? Can LV not cope with changes that aren't wrapped in an Undo transaction?

Snippet included as an attachment, rather than an image.

I can't get this to work programmatically. If I manually set a VI's protection to password-protected through the VI Properties window, then unprotect it again, I see the Undo history is emptied. However, if I programmatically invoke LockState.Set with Password-protected, then invoke LockState.Set with Not Locked, the VI undo history remains in tact. Inserting a Save.Instrument makes no difference either. The Undo history always persists! Any thoughts anyone? Below is a snippet of some example code that attempts to prove that password protection of a VI clears the undo history. It creates a new VI, uses a Windows API call to simulate a standard window move operation as normally performed by an operator, then sets and unsets a password to clear the undo operation but it remains intact. (I will get the snippet up here once I figure out how!)

Thanks Darin. I'll try that. Presumably if I take my target VI, apply a password, remove the password, I'll find the undo history is blank and the VI remains unprotected. Cheers! Edit: it seems LAVA now thinks I'm no longer "Thoric" but "Riggy" !?

I want to clear a VI's undo history, programmatically, from another VI. I see in 2013 that saving doesn't clear the history, so my original plan to simply save my target VI somewhere isn't working. Is there a scripting technique that will obliterate the undo history?? A quick search didn't find anything.

Here: http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

Thanks Darren, this is an interesting function. Kudos for putting this together for me.

OK, so this is where I'm at. Taking Darren's code segment above and slowly adding my own code to it until the Save Request issue arises, I see that it occurs as soon as I dock both the front panel and block diagram of the scripted VI into two individual containers. If I dock just one, or neither, LabVIEW doesn't ask me to save the VI when I close it. By 'docking into a container' I mean changing the parents of the scripted VI windows, using a winapi call. My intention is to 'contain' these two windows to control their access from within my own environment. I presume that once both the front panel and block diagram windows are re-adopted LabVIEW internally identifies unsaved changes?

Jack. That's. Just. Awesome. I can see how powerful and reusable such a scheme would be. I'll be giving that a go (or at least a basic framework akin to what you describe) and I'll approach you directly, if that's ok, should I get a bit stuck. Thank you