Problem with WindowEvent() - Possible Bug?

[Michel_k17]

I've written a small program that only provides a progress bar which updates every 20 ms. The program checks for a file to be created by another program. Once the file is created, the progress bar goes to 100% for 300ms, and then quits.

I was using (pseudo code):

Code: Select all

Repeat
   ; Check for events (to prevent mouse from showing as an hourglass)
   event = WindowEvent()
   ; Check every 20 ms
   delay(20)
   ; Update the progress bar
   Show_Progress()
   ; attempt to rename target file to itself (fails if file not yet created)
   Result = RenameFile(OutputFile$, OutputFile$)
Until Result = #True

; Show 100% Complete
Show_Progress(100)
Delay(300)

The problem was that it was taking 11 seconds to report that the file was created, no matter how small the file was. I could get it to report the file as having been created much more quickly by clicking anywhere on the window!

I changed the code to use a timer (really wanted to avoid using a timer... oh well ) and that works well: small files are reported as being created in 3 seconds (as expected). Here's the pseudo code:

Code: Select all

;Setup a 20 ms timer
SetTimer_(WindowID(),1,20,0)

Repeat
   ; Check for events (to prevent mouse from showing as an hourglass)
   event = WindowEvent()
   If Event = #WM_TIMER
      ; Update the progress bar
      Show_Progress()
      ; attempt to rename target file to itself (fails if file not yet created)
      Result = RenameFile(OutputFile$, OutputFile$)
   Endif
Until Result = #True

; Show 100% Complete
Show_Progress(100)
Delay(300)

For some reason, WindowEvent() is affecting the Rename() command. Instead of checking for the file using the Rename() command, I tried ExamineDirectory() and OpenFile() and got the same results.

It this a PB bug, or am I doing something wrong?

[Dare2]

What happens if you change:

Code: Select all

Until Result = #TRUE

to

Code: Select all

Until Result

?

[Michel_k17]

Thank you for the suggestion.

There was no Difference. By the way, #True is a constant which I have set equal to 1. My observation is based on a version which logged the value of Result and WindowEvent(). It is pretty clear that Result = 0 (ie = #False) until I click the mouse somewhere on the Window. Then, like magic, the Rename() command returns 1 (= #True) on the very next pass (20 ms later). If I don't click on the window, then the Rename command continues to return "0" for 11 seconds (even though the file was created in about 3 seconds).

Seems like a bug to me. I'm just desperately hoping that I am responsible somehow.

[Pupil]

Your first example is plain wrong as you stop the normal handling of events by putting a delay() even if there's events that need to be handled. i Would say that this is a clear case for using timers or starting some sort of timing thread that comunicates with the main process, as this will not halt the window event dispatch process(halting will result in gadget and window flickering).

[Michel_k17]

Not sure I agree with your "this is wrong" statement, as this window has no gadgets whatsoever for the user to interface with. This is a tiny window with only a progress bar displayed. The progress bar is drawn with a box - I am not using the progress bar gadget.

To be sure though, I ran the same code with delay(1) instead of delay(20) and I got the same result: it still took 11 seconds to show that a file had been created - unless I click in the window somewhere, in which case, the file is reported as created in only 3 seconds.

[Pupil]

You should always make sure that the messages/events your window recieves are taken care of as soon as possible, putting a delay() there disregarding that an event occur or not isn't, IMHO, a good coding style... Your window gets events the whole time, i.e. when mouse enter the window area, when mouse is moved inside window, when a window needs redrawing etc.

[Dare2]

Hi Pupil,

Perhaps you can clarify and tell me if this is correct:

With the delay, the program "stops" there, stopping everything to do with the program. Or almost everything?

Are the events backed up or queued, and only trickle through, one event per iteration of the loop?

Whereas with the timer, all events are still getting through, only the desired event is captured and used?

And would WaitWindowsEvent v WindowsEvent be useful here?

[Pupil]

With the delay, the program "stops" there, stopping everything to do with the program. Or almost everything?

Yes, the program stops there and gives the OS aprox. 20ms to do with as it wants.

Are the events backed up or queued, and only trickle through, one event per iteration of the loop?

Yes, to the extent of my knowledge i believe that the messages are qued, but it wouldn't surprise me if many messages were lost too.

Whereas with the timer, all events are still getting through, only the desired event is captured and used?

Yes

And would WaitWindowsEvent v WindowsEvent be useful here?

Together with the timer either would do, doing it manually like in the first example wouldn't work unless you move the mouse around alot as the program wouldn't continue past the waitwindow() command until an event occurs.

[Dare2]

Hi Pupil, and thanks.