[GEM-dev] [PD] bringing the GEM fullscreen window to front in Windows: issue (a second gem window appears)

[cyrille henry]

hello,
you're using windows?
have you try the [topmost $1< message to the gemwin? ($1 = 0 or 1)
if it work, then it's probably easier than an external "switcher"


anyway, what's happen if you don't close the gemwin?
you can close / reload your patch, but having the gemwin in an other patch so you don't have to close it.


cyrille


matteo sisti sette a écrit :
> Hi,
> 
> I am working on a performance in which one of the visual projections
> (i.e. one of the computers) works like this:
> 
> The performance has several "scenes" or "parts"; in some of the parts
> the graphics are made in Flash and run in a standalone Flash Players;
> in other parts they are made in GEM; both run on the same computer and
> are shown in the same projection: in any given part you see either GEM
> or Flash graphics.
> 
> In order to gracefully switch between the two platforms, we do like this:
> Both the Flash Player and GEM run at fullscreen.
> When one of them is "active", i.e. doing interesting things, the other
> one is "idle" that is is displaying a black screen.
> A third application, which I will call the "switcher", which I didn't
> write, uses Windows' API to bring to front in each scene the
> application that needs to be seen: either GEM of Flash.
> 
> Everything works fine and we've performed live more than once without problems.
> 
> But there is an annoying issue, especially in rehearsals, that i'd
> like to know if I can work around.
> 
> When we end a rehearsal and want to start over again we do like this:
> 
> I close the GEM window by sending a [destroy( message to [gemwin]
> I close the "switcher" application.
> I close the flash player
> I restart the flash player
> I recreate the GEM window by sending a [create( message to [gemwin]
> I start the "switcher" application.
> 
> Now the problem is that, as soon as the switcher tries to bring GEM to
> front, a second GEM "window" appear, so I get two gem windows none of
> which is rendering.
> There's no way to close them both, as a [destroy( message will only
> destroy one of them, and any further [destroy( message won't destroy
> the second gem window.
> 
> The only way to restore normal functioning is to quit and restart PD.
> 
> 
> I don't know if this is relevant, but there is another instance of PD
> running in the same machine: this one DOESN'T load GEM and runs in
> -nogui mode in a "msdos" window (it runs a simple patch that receives
> udp packets and convert them in midi messages sent to a midiyoke port
> and viceversa).
> Thought I am not sure, I got the impression that just restarting the
> PD/GEM is not sufficient to avoid the problem: it seems that I have to
> restart both PD instances, even the one that does not even load gem
> (let alone create a gemwin).
> Is it possible?
> 
> 
> Now, I am a C++ analphabet (almost), but I'll try to give as much
> information as I can about the way the "switcher" works.
> 
> It uses the method:
> HWND hAppHwnd = ::FindWindow(NULL, _T("GEM"));
> and then:
> ::SetWindowPos(hAppHwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_SHOWWINDOW |
> SWP_NOMOVE | SWP_NOSIZE);
> 
> 
> The person who wrote the switcher assured me that the two calls are
> done each time GEM needs to be brought to front, i.e. it DOESN'T
> create the hAppHwnd handler at the beginning and then reuse the same
> handler each time: it gets the handler from scratch each time.
> 
> Note: the switcher NEVER closes nor tries to close the GEM window: I
> always destroy and create it with [create( and [destroy( messages to
> [gemwin]
> 
> Also, I run the "switcher" after creating the gem window and close it
> before destroying the GEM window, so he is never trying to bring to
> front the GEM window when it doesn't exist.
> 
> 
> ............... any clue?
> Or if not, what circumstances in general may cause a second spurious
> gem window to be created?
> 
> Thanks in advance
> m.
>