Running Windows Processes and making their Window Topmost

[jcambiasso]

This is actually more of a Windows question, but since I am doing this in a Labview context, maybe you guys can help. I'm using LV17 and Windows 10. I need to run a Windows process, specifically I'm calling "control.exe date/time", in an application intended to run fullscreen and the user doesn't have a keyboard. I used Labview's System exec.vi, a Call Library Function to WinExec() and even made my own .NET Class Library. 

The Windows Date/Time configuration window does indeed run, the problem is it does with its windows behind the calling Vi's frontpanel. User has to alt-tab to access it, something that's not desirable. I tried bringing its named window to the front and bringing the calling VI's Front panel to the bottom, with FindWindow() from winuser.h, everything to no avail. 

Other processes and applications do work (calculator.exe, Notepad.exe) without much hassle, the problem is control.exe with arguments, and I suspect any other process that run another process in a separate thread. 

Has anyone ever had to do something similar and could overcame this issue? 

Thanks! 

[BowenM]

It sounds like you might have tried this, which will call windows API to move it to front.

If that doesn't work, you can check the libraries available here. Open up the "WINUTIL.llb" and there is a call to "Make Windows Always on Top".

If neither of those work then I'm stumped.

[jcambiasso]

Thanks for the links. Yes, I did try the first one's methods, altough the control panel Windows may change due to language and I have to hardcode the window's name. Also I need to hardcode a timer to wait for the window to actually open. Neither of those little nuances are desirables.

Will try the second set of files, thank you very much. I will keep you posted.

[jcambiasso]

Ok, so I had to go for the lesser evil, and do the following:

ProcessHandler is just a static class that wraps the above mentioned native libraries in a nice little .NET Class Library. I had no other choice but to wait for the window to run and get it's handler based on a hardcoded string. Given that we ship our solution in multiple window's languages, I have to hardcode the other titles too. It's nasty, but could not divise any other solution.

[zou]

If you are more comfortable with .net than LabVIEW, you might want to try .net start process with WaitForInputIdle Method.

The advantages:

1. you don't have to poll windowhandle in LabVIEW to see if the window has been created;

2. you get the process reference of the newly created process.  you might be able to get the date/time window from the properties of the process, such as MainWindowHandle, or MainWindowTitle.  So that you don't have to hardcode date/time in other languages.

Not sure if it works in your case, but worth to try.

[jcambiasso]

---

@zou  ha escrito:

If you are more comfortable with .net than LabVIEW, you might want to try .net start process with WaitForInputIdle Method.

The advantages:

1. you don't have to poll windowhandle in LabVIEW to see if the window has been created;

2. you get the process reference of the newly created process.  you might be able to get the date/time window from the properties of the process, such as MainWindowHandle, or MainWindowTitle.  So that you don't have to hardcode date/time in other languages.

Not sure if it works in your case, but worth to try.

---

Thanks for the input! Yes, actually that's why I made a .NET class library right away; I knew the Process class had a MainWindowHandle property I could leverage for this. That StartProcessOnTopSync method does exactly that. But it looks like control.exe with the date/time argument just fires up windowless (thus no Window handle whatsoever), runs another process (probably rundll32.exe) and inmediately closes, so the WaitForExit or WaitForInputIddle methods neither work, at least for me in this case. 

[zou · Accepted solution]

Don't use "control.exe date/time".

Use 

%windir%\System32\rundll32.exe shell32.dll,Control_RunDLL timedate.cpl

You will get the new the real process reference back.  I've already tried.

From the process, you can enumerate all threads and windows in it.

Only one visible window in the process.

Rundll is the owner window of the Date and Time window.  It's invisible.  And no title.

Both windows belong to the new process.

[jcambiasso]

---

@zou  ha escrito:

Don't use "control.exe date/time".

Use 

%windir%\System32\rundll32.exe shell32.dll,Control_RunDLL timedate.cpl

You will get the new the real process reference back.  I've already tried.

From the process, you can enumerate all threads and windows in it.

Only one visible window in the process.

Rundll is the owner window of the Date and Time window.  It's invisible.  And no title.

Both windows belong to the new process.

---

Yes! That's the correct path! I didn't even have to modify the class library, just call the new arguments.

Thank you very much! Issue is closed and solved.