Post-Build Hook VIs don't come to the front

[crelf]

Even if I set a subVI of my post-build hook VI to modal, it stays behind the VIPM and package builder windows.

[JKI]

Even if I set a subVI of my post-build hook VI to modal, it stays behind the VIPM and package builder windows.

 

The reason for this is that build hook VIs run in the target LabVIEW development environment and VIPM is its own executable application. So, opening a modal dialog in LabVIEW won't make the build hook's dialog come frontmost, if LabVIEW isn't frontmost (which it won't be, since you're probably interacting with VIPM).

 

Also, build hooks can do anything they like, but VIPM has no way to know that you intend them to have user interaction.

 

There are at least a couple possible ways to address your use case.

 

1) VIPM could possibly make LabVIEW frontmost while it is running the build hooks and then bring itself frontmost again after the build hook completes execution.

 

2) The build hook could make itself come frontmost -- this can be done with Windows API calls. It should be careful to bring VIPM frontmost again, after it's done, so that the user doesn't wonder why VIPM went away.

 

I'm trying to think if #1 would cause any usability problems for running build hooks that are not user-facing. One solution might be to have a "bring LabVIEW to front when running build hooks" option, but I really dislike adding new options, if it's possible (even with a bit of work) to make the software simply work as expected in all situations.

[crelf]

There are at least a couple possible ways to address your use case.

Yeah - I don't think that there's an easy answer to this one. Maybe the answer is a hybrid of the two: I don't mind putting the user32.dll call in my build-hook VI to bring itself to the front, but then maybe the package builder could bring itself to the front after the build-hook has finished (if it's already at the front, then that would still work fine too). This should cover both user-facing and non-user-facing use cases.

[Jim Kring]

Yeah - I don't think that there's an easy answer to this one. Maybe the answer is a hybrid of the two: I don't mind putting the user32.dll call in my build-hook VI to bring itself to the front, but then maybe the package builder could bring itself to the front after the build-hook has finished (if it's already at the front, then that would still work fine too). This should cover both user-facing and non-user-facing use cases.

 

I don't know if it's easy to detect the frontmost application/window. Do you know? Plus, I don't know if it's a good idea to add such a feature to VIPM, just to handle a situation where a build-hook *might* make itself frontmost. How does VIPM know that the reason VIPM is no longer frontmost is because of a build-hook? Maybe it's because the user clicked on another application to do some work while VIPM builds.

 

As a short-term solution, I would suggest trying to have your build-hook make VIPM frontmost after the user interaction with your build-hook is finished.

[crelf]

I don't know if it's a good idea to add such a feature to VIPM, just to handle a situation where a build-hook *might* make itself frontmost. How does VIPM know that the reason VIPM is no longer frontmost is because of a build-hook? Maybe it's because the user clicked on another application to do some work while VIPM builds.

That's kinda standard practise though - if your software is doing something in the background, and then wants user input it either brings itself to the foreground or posts a message to make it's task bar item flash.

 

As a short-term solution, I would suggest trying to have your build-hook make VIPM frontmost after the user interaction with your build-hook is finished.

Sure - If I can find the hWnd of the VIPM package builder window and set it to frontmost. The only way I know how to find the hWnd is by using the user32.dll FindWindow() function, which needs the title bar text to search on - does the VIPM have a standard that it follows during post-build hook exectuion that I can reliably know?

[JKI]

That's kinda standard practise though - if your software is doing something in the background, and then wants user input it either brings itself to the foreground or posts a message to make it's task bar item flash.

 

I can see a case for having VIPM bring itself to the front after the package build is complete -- it does present a dialog telling the user that the build has completed. I'll pass this along to the rest of the VIPM developer team.

 

Sure - If I can find the hWnd of the VIPM package builder window and set it to frontmost. The only way I know how to find the hWnd is by using the user32.dll FindWindow() function, which needs the title bar text to search on - does the VIPM have a standard that it follows during post-build hook exectuion that I can reliably know?

 

The window title of VIPM's package building window is "PACKAGENAME - VIPM - VI Package Builder". Note that PACKAGENAME does not include the version number.

[crelf]

I can see a case for having VIPM bring itself to the front after the package build is complete...

That's what I wanted to hear!

 

The window title of VIPM's package building window is "PACKAGENAME - VIPM - VI Package Builder". Note that PACKAGENAME does not include the version number.

Thanks - I'll implement that for the time being.