Child process needs to stay in front of parent
-
I have a parent application that acts as a process handler of sorts. When it starts a child process, I need that child process to stay in the foreground. Normally, if the user doesn't interact with the screen, the child process starts and it's window fills the screen, and everything is fine, and the user can interact as expected.
The problem is, if the user touches the screen in that brief moment before the child process has fully started, Windows assumes they are trying to interact with the parent process's window and keeps it in the foreground, and the child process ends up starting with it's window behind the parent. This gives the appearance that nothing happened and the system is stuck on the splash screen.
This is an embedded system, so it's all locked down, no keyboard shortcuts work. You can't just Alt+tab to get the child process back. Is there a way I can tell the QProcess to keep itself in the foreground? I know that the child process can have windows flags set to keep it in the foreground, but this will make QAs job much more difficult - so unless I can pass windows flags as an argument some how, that's a no go.
-
I have a parent application that acts as a process handler of sorts. When it starts a child process, I need that child process to stay in the foreground. Normally, if the user doesn't interact with the screen, the child process starts and it's window fills the screen, and everything is fine, and the user can interact as expected.
The problem is, if the user touches the screen in that brief moment before the child process has fully started, Windows assumes they are trying to interact with the parent process's window and keeps it in the foreground, and the child process ends up starting with it's window behind the parent. This gives the appearance that nothing happened and the system is stuck on the splash screen.
This is an embedded system, so it's all locked down, no keyboard shortcuts work. You can't just Alt+tab to get the child process back. Is there a way I can tell the QProcess to keep itself in the foreground? I know that the child process can have windows flags set to keep it in the foreground, but this will make QAs job much more difficult - so unless I can pass windows flags as an argument some how, that's a no go.
@bmarzolf You can call
setWindowFlags(Qt::WindowStaysOnTopHint)in your child app, so it will stay on top all the time.
See https://doc.qt.io/qt-5/qt.html#WindowType-enum -
Yes I know, but as I stated, this is not allowed because it prevents QA from running their tests. I would need to be able to pass that flag to the child as an option, so that it can be set if desired, but not set during QA.
-
I have a parent application that acts as a process handler of sorts. When it starts a child process, I need that child process to stay in the foreground. Normally, if the user doesn't interact with the screen, the child process starts and it's window fills the screen, and everything is fine, and the user can interact as expected.
The problem is, if the user touches the screen in that brief moment before the child process has fully started, Windows assumes they are trying to interact with the parent process's window and keeps it in the foreground, and the child process ends up starting with it's window behind the parent. This gives the appearance that nothing happened and the system is stuck on the splash screen.
This is an embedded system, so it's all locked down, no keyboard shortcuts work. You can't just Alt+tab to get the child process back. Is there a way I can tell the QProcess to keep itself in the foreground? I know that the child process can have windows flags set to keep it in the foreground, but this will make QAs job much more difficult - so unless I can pass windows flags as an argument some how, that's a no go.
-
@bmarzolf
Hi
Could you not just add a parameter to the call to start the other process so it knows
if to use WindowStaysOnTopHint or not?
That assumes you have the code for the child process else it's not an option ofc. -
@bmarzolf you could simply call rise() after show(). That should rise the child process to the end of the draw list.
You can delay it with a QQueudConection call or a timer, that way it should be at the end, after the mouseEvents
-
@J-Hilk There is no rise() function for QProcess, and one uses start() not show() to start the process.
-
I have a parent application that acts as a process handler of sorts. When it starts a child process, I need that child process to stay in the foreground. Normally, if the user doesn't interact with the screen, the child process starts and it's window fills the screen, and everything is fine, and the user can interact as expected.
The problem is, if the user touches the screen in that brief moment before the child process has fully started, Windows assumes they are trying to interact with the parent process's window and keeps it in the foreground, and the child process ends up starting with it's window behind the parent. This gives the appearance that nothing happened and the system is stuck on the splash screen.
This is an embedded system, so it's all locked down, no keyboard shortcuts work. You can't just Alt+tab to get the child process back. Is there a way I can tell the QProcess to keep itself in the foreground? I know that the child process can have windows flags set to keep it in the foreground, but this will make QAs job much more difficult - so unless I can pass windows flags as an argument some how, that's a no go.
@bmarzolf
Sorry, humour me, it may be obvious to others but not to me...."Your" program is the "parent" here, the one that is kicking off the
QProcess, right? The potential child processes are GUI programs, right? And you are in charge of the parent/Qt application here, right? And (contrary to some suggestions) you can't send parameters to the child processes, because they are not your source code, right?Then when the user touches, it is the parent which comes up front, and you wanted but can't get the child to stay on top as it would have done, right?
So your app probably cannot bring the child back up front if I recall correctly that Windows doesn't let a process bring another one up-front? Is there a Windows call instead for "push myself to back" which you could use with a delay after starting the child process? Or could you minimize your parent before spawning child and restore yourself on child finish? Or, is there a call to block/ignore touch events so Windows won't bring you up-front which you could make prior to launching the child?
-
@bmarzolf
Sorry, humour me, it may be obvious to others but not to me...."Your" program is the "parent" here, the one that is kicking off the
QProcess, right? The potential child processes are GUI programs, right? And you are in charge of the parent/Qt application here, right? And (contrary to some suggestions) you can't send parameters to the child processes, because they are not your source code, right?Then when the user touches, it is the parent which comes up front, and you wanted but can't get the child to stay on top as it would have done, right?
So your app probably cannot bring the child back up front if I recall correctly that Windows doesn't let a process bring another one up-front? Is there a Windows call instead for "push myself to back" which you could use with a delay after starting the child process? Or could you minimize your parent before spawning child and restore yourself on child finish? Or, is there a call to block/ignore touch events so Windows won't bring you up-front which you could make prior to launching the child?
@JonB This is correct.
In theory there is a windows api for this. I started down that rabbit hole and quickly backed out of it because it's a lot of work to track down the correct process.I may have found a solution, but I'm not happy with it:
powershell -ExecutionPolicy bypass -Command "add-type -AssemblyName Microsoft.VisualBasic; [Microsoft.VisualBasic.Interaction]::AppActivate(process->processId)"Call that from a QProcess::start(), depending on how finicky your system is you may need to break it into the "powershell" command and a QStringList of arguments, but that does pull the child process to the front.
