Hook into Save VI?

[Black Pearl]

I'm working on integrating mercurial/Hg into the LV IDE.

At the moment I have a nice menu entry called Save & Commit. Well, that's a understatement.

1. Check the mod bitsets of the vi

2. Save the vi

3. Commit the vi with user defined message

4. Add the mod.bitset in human readable version to the commit-log.

It's some really nice automgic I have running right now. However it requires the user to select the menu entry. Using save or closing a vi and then saving (saving subVIs) is resetting the mod.bitset. And that would be the really cool way of having it integrated, all vi's that are only changed due to a recompile are marked as such, hence you can ignore them in a merge!

So what I wish to have is a hook or hack into the Save procedure.

As usual, I'm open for black magic, dirty hacks (redirects of dll calls), scripting background services and the like...

So far our best idea was a global hotkey-assignment of the Ctrl+S key via AutoIt.

Felix

[Grampa_of_Oliva_n_Eden]

I'm working on integrating mercurial/Hg into the LV IDE.

At the moment I have a nice menu entry called Save & Commit. Well, that's a understatement.

1. Check the mod bitsets of the vi

2. Save the vi

3. Commit the vi with user defined message

4. Add the mod.bitset in human readable version to the commit-log.

It's some really nice automgic I have running right now. However it requires the user to select the menu entry. Using save or closing a vi and then saving (saving subVIs) is resetting the mod.bitset. And that would be the really cool way of having it integrated, all vi's that are only changed due to a recompile are marked as such, hence you can ignore them in a merge!

So what I wish to have is a hook or hack into the Save procedure.

As usual, I'm open for black magic, dirty hacks (redirects of dll calls), scripting background services and the like...

So far our best idea was a global hotkey-assignment of the Ctrl+S key via AutoIt.

Felix

I believe it was code from the MS web-site called "Procmon" or something similar. When run it logs all system calls and access to dll's etc. Run it while LV is running and you may find a hook.

That is all I can offer.

Ben

[ShaunR]

Don't have a definitive answer. But some things perhaps you could look at.

Under the App properties there is a "source Control" sub menu that look interesting. Looks like a hook into the LV source control stuff (read/write config looks interesting) . Maybe you could find a way to make Labview Mercurial aware!

A bit of a kludge. But you could monitor the revision number and action when it changes. As far as I'm aware, it is only up-issued after a save rather than a compile.

[vugie]

Monitor when "*" disappears from title bar of window which has a focus. Was there a "Modified" property of VI (or sth like this)? I can't check it now.

[Black Pearl]

Ben: I'll look into this

ShaunR: I'm on FDS, so I don't get the SCC menu.

But the point is very interesting. If you look at the default menu (all is tested unter 7.1 only), you get the tools (project folder) menu and the help (?) menu listed, but not the wizards folder (which inserts between new and close). The AppBuilder can be seperatly purchased to the FDS and is inserted at it`s own unique place in the menu. I'm unsure about all this, because private property nodes already allow you to check if you have an AppBuilder. So it might be hardcoded support in the LabVIEW.exe and/or there are hooks.

vugie: there is a 'modified' boolean. This is my worst-case attack to monitor this for all vi's and if it's going from true to false, I know the vi has changed and was saved. So then I would poll the mod.bitsets as well and commit on flag down with a comment of these bitsets. But I dislike the option of a constant polling background service.

Felix

[Black Pearl]

Using procmon I found a hook that seems to have been overlooked so far:

lv_quit.vi

It's a bit difficult to get this working, as if you close it's FP, it just get's called again. I propably need to rename the file programatically to allow LV to shut down...

Furthermore it's called after the the close, so Menu Activation VI returns an empty string. As I don't know if the vi was saved before the close, I can't directly use the MRU list.

But propably I could use it to send triggers to a background service...

Felix

[Black Pearl]

Using procmon is fun. I found a lv_subvi.vit. Boah!

Well the first hint was googling for lv_quit.vi; I found a server where I don't have access to (but somehow I got some google-hit which displayed the line). It seems to be some lego toy library. So anyone who has a kid at that age, please search for these files on your kids PC.

Well, any attempts to use it resulted in a crash.

I thought I could upgrade my old 7.1 to 2011.

As another dark alternative, I found some obscure ini keys that give access to some internals. First let's me load but not modify some menus, I think it's the the real IDE menus. The second one gives me all the 'dialog' that show up but are not present as a vi. Well, they just consist of the FP, the terminals are not connected. Wonder if I could place some code there.

Anyhow, I'll need to setup a sandbox to mess around with this.

Well, lesson learned as young novice of the black magic. Feed that google-engine the right keywords, and you get access to too many secrets you shouldn't know.

Otherway round: if you need to keep a secret, fear big brother google.

For the historians, there is an old lava mailinglist out there in cyber space .

Felix

[vugie]

.. The second one gives me all the 'dialog' that show up but are not present as a vi. Well, they just consist of the FP, the terminals are not connected. Wonder if I could place some code there.

...

They may be templates for some xnodes. Putting code there could work, but his depends on how xnodes put their code into templates.

[Grampa_of_Oliva_n_Eden]

Using procmon is fun. I found a lv_subvi.vit. Boah!

...

Felix

I am torn between wondering if I created a monster or if I am just feeding one.

RE:Big Brother

The less you post about holes the longer it will be until that board grad student decides they will implement the first LV virus.

Wink, wink, nudge, nudge, say no more say no more." (M Python)

Ben

[Aristos Queue]

As another dark alternative, I found some obscure ini keys that give access to some internals. First let's me load but not modify some menus, I think it's the the real IDE menus. The second one gives me all the 'dialog' that show up but are not present as a vi. Well, they just consist of the FP, the terminals are not connected. Wonder if I could place some code there.

Nope. The code for those dialogs is all written in C++. When a VI compiles, it generates assembly code for its run proc. For those VIs, when they load, we swap the pointer to the code block with a pointer to C++ code already compiled into LV. The diagram never executes.

Can you dynamically register for the "Close Panel?" event on every VI in memory? Put up a poll for "all VIs in memory" that runs every 1/2 second or so and register for the "close panel?" event. I don't know how well that would work but it seems like something you haven't tried yet.

[ShaunR]

Can you dynamically register for the "Close Panel?" event on every VI in memory? Put up a poll for "all VIs in memory" that runs every 1/2 second or so and register for the "close panel?" event. I don't know how well that would work but it seems like something you haven't tried yet.

I think the target VI would have to be running to be able to hook that event.

[Black Pearl]

Thanks AQ, so I don't need to try the dialogs.

Using Close Panel? was among my first attempts. The events only get fired if the vi is running. Also I can't register if the vi is broken.

Felix