setForeground() does it work?

Unless I’m using this wrong (I may well be) I’m using setForeground() in python to re-activate / re-focus a touchplayer window once it’s been un-focussed for a set period of time (15 seconds) I run a chop execute and in the performance monitor the status of the perform_focus indicates 1 (that the window is focussed) but the window remains unfocussed / unactivated… am I missing something? can I even control this Windows focus function in Touch?

hey @responsve are you using the method from the Window COMP class?

This assumes that TouchDesigner is already the focused application, and allows you to move which TD window COMP is currently on top - assuming that you had multiple open. If you’re looking to access the focused window for the operating system you’d likely need an operating system call - which is very doable, just a little more python.

Are you looking to change the order of multiple TD windows, or make sure that TD is the focused application? Also - what’s the OS you’re running?

Hey @raganmd, yes I had success with it focusing a TD window, but only within TD. I couldn’t figure out how to use it to set the focussed window within the Windows 10 operating system context, which is what I’m trying to achieve. What python operating system call would you use? I’m just attempting to maintain TD as the focused application after a timeout, so it retains keyboard control in all circumstances. I’ve used an external script to achieve this for now, but a built in TD solution would be best

I think the win32gui library is what you’re after. There’s some interesting chatter on stackoverflow here

I’d consider either pulling the library into your project, and then including that module in touch, or pulling it into a local install of python, and setting Touch to look for your external libraries. Either way, one of these externals is likely the way to go. Give a ping if you’re still stuck and I’d be happy to help you trouble shoot.

Thanks so much for this bro, I’ll investigate, and will be in touch if I’m stuck for sure, cheers!

Do you specifically need keyboard input? Or just window focus?
The tips in that article seem helpful (I’ll try adding them to setForeground to see if it makes it a bit more robust), but they do say they it fails to set the keyboard focus still.
How is TD losing focus in this case?

The hack from the above article will be done by setForeground in the next 2019.30000 release. Thanks for the report, hopefully this helps a little…

1 Like

Brilliant, thanks @malcolm, specifically I’d use this within TD to maintain keyboard input while an installation is running… in case of it losing focus from interruptions (such a a remote login, windows or another user)

I don’t know if this fix helps with keyboard focus though, just window focus. Answers in that post give mixed results

Hi,

Re-activating this topic as I’m struggling with a similar issue.

TD triggers Unity build that are spouted in the workflow.

As soon the unity build pop up, TD loose the focus and drops frames.

Most of the Gpu ressource being allocated to Unity.

I tried the setPerform () method but it doesn’t work as I expected.

From my windowComp (perform) running this script : parent().setForeground() and printing the result.

Even if something happens in the windows taskbar : TD’s icon is flashing orange ( but not as the regular state, light grey, for the focus application)

It will return False and the frame rate doesn’t get better.

I still need to click inside the output’s window to get the focus back and get a decent frame rate ( GPU ressource about 50-50 between Unity & TD).

I tried with some less greedy unity scene with exactly the same result.

It seems that Unity manages , even if not in focus, to maintain the minimum ressource to render, going from 80% to 50%, never less.

while TD will drop down to 3 fps !!!

@malcolm : I’m running the last build (2020.24380). Have you successfully integrated the hack mentioned above ?

Am I doing something wrong with the method call?

It is very similar to the description in the first post :

What you have to do is disable the foreground lock. Turns out it was as easy as this:
win32gui.SystemParametersInfo(win32con.SPI_SETFOREGROUNDLOCKTIMEOUT, 0, win32con.SPIF_SENDWINI

Do you think it could be the issue ?

I will give a try with the pywin32 library .

Thanks

Not sure how to explain the Unity vs. TD difference in terms of FPS there. I wonder if it’s the OS or the graphics driver that is responsible for how GPU time is partitioned. I’ll try to ask nvidia about that.
The hack is in, but it is indeed a hack. It’s entirely possible that that a Windows Update changed the behavior. From an OS design perspective it makes sense to me that you wouldn’t allow one application to force itself to the foreground arbitrarily, so it doesn’t surprise me that Windows reduces our attempt to just a flashing icon on the taskbar.