11-10-2022, 01:20 AM
(11-10-2022, 12:35 AM)SMcNeill Wrote:(11-10-2022, 12:00 AM)Pete Wrote: The real need here is to get something Windows is very poor at doing, forcing a window to be active. Spriggsy and I both found slightly different methods with a common requirement. You have to write code to minimize the window and restore it. Doing that forces it active. The downside is the slight loss of window effect or the effect of seeing the window go to the task bar and back. I mention the two visuals because you could hide the window before minimizing it, which gets rid of the task bar trip effect. Anyway, this was the way I got the TCP/IP messenger app user friendly.
Pete
https://staging.qb64phoenix.com/showthre...44#pid8744 -- Was this not what you were looking for?
No unfortunately, it doesn't . That's a persistency routine. I already have a couple of methods I've coded in the past to keep a window persistent (on top) which is what your snippet does. It's a whole different shooting match forcing it to be "active." Try your routine, and click an open window running on your desktop. Your window is coded to stay on top but the focus will be on the other window you clicked. With the min/restore trick, you can keep your app in focus. Windows devs should have created a simple way to achieve that effect, without minimizing and restoring. SetActiveWindow just doesn't cut it as far as my research discovered. I get it, they probably feel the user should determine the active window, not a process.
Thanks for taking a shot at it though though,
Pete