OpenEuphoria

Re: Win32lib an onClick (+fan mail)

• Posted by "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV> Feb 16, 2000
• 489 views

Bernie wrote:

> Shouldn't a user be able to use your
> onEvent to monitor the event loop?
> This would be easier than rewriting
> the message loop.

The problem is that *no* events are going to be seen if the application is
in a tight loop. Windows places events (button presses, mouse movements,
etc) in a queue for the application to respond to. The core of WinMain more
or less like this:

   -- get a message; exits when message is WM_QUIT
   while GetMessage do
      -- map virtual WM_KEYDOWN messages into ANSI WM_CHAR
      TranslateMessage
      -- trigger callback (WndProc or SubProc)
      DispatchMessage
   end while

So if you have something like this:

   for i = 1 to 100000 do
      doSomethingComplex()
   end for

and press a button, the event is added to the message queue, but doesn't get
handled until the loop is exited. Rather than timeslicing, it's probably
better to add a routine to the loop to check for pending messages. For
example:

   for i = 1 to 100000 do
      doSomethingComplex()
      doQueuedEvents()
   end for

That way, events that are accumulating are handled while the task continues.
Here's a possible implementation (thanks to Brian Jackson):

   global procedure doQueuedEvents()

      atom msg

      -- allocate a message structure
      msg = allocate_struct( SIZEOF_MESSAGE )

      -- if there's a message, handle it
      if c_func( xGetMessage, { msg, NULL, 0, 0 } ) then
         c_proc( xTranslateMessage, { msg } )
         c_proc( xDispatchMessage, { msg } )
       end if

      -- free the message structure
      free( msg )

   end procedure

Brian notes that it's dog slow, so you probably don't want to call it on
every iteration through the loop.

Keep in mind that processing events may cause interesting things to happen.
For example, if the user could change the state of the application (resize
the window) that would pull the carpet out from under whatever your
application is doing.

In another scenario, the user could close the application while the
processing is going on, and bad things could happen. This is because WinMain
would never see the WM_QUIT message (doQueuedEvents got it first). It's
possible that Windows would start returning error as a result (-1). Since
WinMain uses a while() in the loop, it could get stuck in an endless loop...

I'll need to think about this a bit.

-- David Cuny