Re: Lost in the Windows fun-house
- Posted by Derek Parnell <derekp at SOLACE.COM.AU> Jan 19, 2001
- 495 views
Hi George, I'm not sure if anyone has answered this old note of yours. >-----Original Message----- >From: Euphoria Programming for MS-DOS >[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of George Henry >Sent: Sunday, December 10, 2000 11:04 AM >From my research on the Internet, it appears that it is possible to >dynamically switch a window from Normal to Modal or the reverse *in Linux*. >My question #1 is, is it possible to do this in Windows? Win32lib does not support this functionality, though it would be easy to add in to the library. I was wondering why an application would want to do this sort of thing though. >#2: If, as appears to be the case, in Windows you open a window as either >Normal or Modal, and it stays whichever way you chose until you close it >(which if it works that way is REALLY STUPID), Why is this "REALLY STUPID"? It seems okay to me? What am I missing? >how can I close a window as >Normal, reopen it as Modal, and when the user closes the Modal >version, then >reopen it as Normal? All code sequences I have attempted so far fail to >produce the desired results. For example, this doesn't work: > >procedure onClose_myWin() > if myWin_isModal then > myWin_isModal = False > openWindow(myWin, Normal) > else > setFocus(parentWin) > end if >end procedure > >procedure toModal() > closeWindow(myWin) > myWin_isModal = True > openWindow(myWin, Modal) >end procedure The above code doesn't work because the onClose handler is called before the window has completed closing. After the handler returns control to win32lib, the library then hides the window. It does this because it still thinks it is trying to close the modal window and has not realised that you have "opened" it again as a normal window. If the onClose handler was invoked after the closing process was completed then your code would work, but that's not how it goes. The library behaves in the manner it does because it gives the onClose handler the chance to reject the close request. >Nor does this: > >procedure toModalAndBack() > closeWindow(myWin) > myWin_isModal = True > openWindow(myWin, Modal) >-- Assuming, perhaps erroneously, that control doesn't return here >-- until the modal window is closed: > mWin_isModal = False > openWindow(myWin, Normal) >end procedure The above code doesn't work because control returns immediately after an openWindow() call. Using openWindow(,Normal) on an already opened modal window has no effect - the window remains modal. You might try this idea though... procedure toModalAndBack() closeWindow(myWin) myWin_isModal = True openDialog(myWin) -- Control returns when the modal (dialog) window is closed. mWin_isModal = False openWindow(myWin, Normal) end procedure but this has the side-effect of removing the minimize box on the normal window too. >And question #3 would be, is the assumption indicated in the comment >correct, or does openWindow() spin off another thread of execution? The assumption is not correct, nor does openWindow() spin off an execution thread. Actually all openWindow() does is display a window and allows it to receive interrupts. For a modal window, it also prevents other windows from recieving interrupts until it is closed. This is similar to threaded execution in normal appearances, but when a given window is processing an interrupt, neither it nor other windows can process interrupts. It blocks interrupts while processing the current one. This is why we have a doEvents() call to be used inside event handlers that will run for a long time (say greater than a couple of seconds). integer iCount iCount = 0 procedure ClickHandler(integer self, integer event, sequence parms) -- Ignore clicks if I'm already processing one. if iCount != 0 then return iCount = 1 while .... do -- Give the user a chance to do something before I take control again. doEvents() . . . end while iCount = 0 end procedure setHandler( Button1, w32HClick, routine_id("ClickHandler")) >Puzzled in Windows-land, we ain't in Console-land no more, that's for sure. I'm still puzzled as to why an application would want to cause a window to behave sometimes as modal and sometimes as normal? Wouldn't this be a bit confusing to the operator? ----- cheers, Derek Parnell derekp at solace.com.au Solace Limited ( http://www.solace.com.au ) Melbourne, Australia +61 3 9291 7557