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

matteo sisti sette matteosistisette at gmail.com
Fri Jan 25 11:50:57 CET 2008


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.

-- 
Matteo Sisti Sette
matteosistisette at gmail.com
http://www.matteosistisette.com




More information about the Pd-list mailing list