We’ve noticed that the popup handler of the 3dsmax plugin will not fire till 3dsmax gains focus. I believe this has been first reported a few years back, but it still seems to be the case.
Its sufficient to trigger the popup handling to select 3dsmax, deadline will immediately handle the popup and carry on.
Without manually giving focus, the popup is never detected / handled, and eventually the 3dsmax plugin does a startup timeout.
State of the machine waiting for the popup to be handled, and its log. Nothing is happening, popup is visible, max is not in focus:
Capture.PNG
Giving focus to max, the popup is immediately handled as witnessed by the log, and the job carries on:
I do remember this one. I believe that we usually bring focus to the applications that start, but that code would be in the core code and not exposed to the scripting API. I’m also not sure if we managed to reproduce this, but I’ll have someone over here take a look.
So, today I seem to remember that I had some trouble reproducing this last time we tested. I feel like it’s come up with the MaxScript debugger.
The fact that it’s hit with TP’s dialog is interesting… Do you think if we just created any dialog via MaxScript it would reproduce it? I guess an easy test would be to launch an external command prompt so it steals focus (say by using the start command), then make a popup a few seconds after that?
We can probably hook that into the “deadlineStartupMax20XX.max” script.
What do you think of that test case? Is that worth pursuing or should we attack a reproduction case in a different way?
This popup comes from the TP dll i think, so it would not be scripted. Not sure if you can repro with a scripted one, but it might behave similarly
Huh. Looks like we’ve got this one here in a similar vein (found while I was making an internal issue):
forums.thinkboxsoftware.com/vie … 11&t=15531
I’ll raise it up the ranks and see what we can do.
