Re: Lost in the Windows fun-house

new topic     » topic index » view thread      » older message » newer message

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

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu