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.