[PD] bringing the GEM fullscreen window to front in Windows: issue (a second gem window appears)
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 [EMAIL PROTECTED] http://www.matteosistisette.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bringing the GEM fullscreen window to front in Windows: issue (a second gem window appears)
Hi Cyrille, thanks for your help. you're using windows? Yep. 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 I didn't know about the topmost message! However, I'm afraid I still need the switcher. Turning GEM's topmost on and off would be weaker, i.e. I would need to ensure that just behind GEM is the Flash Player; with the switcher, I always bring to front the needed application no matter who was on front before; it is more reliable and more inmediate to launch everything (without having to click on windows in a certain order to make sure they are where they need to be) 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. The fact is that I don't need to reload the patch while I DO really need to close the GEM window (i.e. destroy the gemwin) between one rehearsal and another. Consider that the GEM window is fullscreen, so I can't move it; also, if it was the last one to be brought to front before the switcher was closed, the GEM window remains permanently topmost, i.e. always on front: unless I close it I can't see anything else (e.g. the patch gui window, the windows desktop, etc.). When I stop a rehearsal and start a new one I tipically need to check out things on the patch GUI, and/or browse Windows folder and edit text files that are later read by the patch. That's why I stop the rehearsal at all: otherwise I would simply go to the beginning of the performance (or to whichever part) which I can do without restarting things at all. I have oversimplified my setup in the description, in order not to bother people with irrelevant details, but the switcher is indeed an application that is doing other things as well; there are other computers with other projections and with audio; and whenever I have to restart the central master computer that controls the whole system (which is not the computer we were talking about), I have to restart the switcher and the flash player. In such situations, I don't mind closing and reopening the GEM window (which I usually need as I mentioned in order to see and access other things) but I wouldn't need to restart/reload the patch and GEM, were it not for this double-gem-window issue. So I'd like to avoid having to restart gem, in order to reduce the number of operations needed to restart the system to a minimum (switcher and flash player automatically quit when the master quits, for example). That's why I'm trying to figure out what's the reason of this double-gem-window weirdness, in case there's a solution. Thanks again m. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bringing the GEM fullscreen window to front in Windows: issue (a second gem window appears)
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
