Window behaviour question [solved]

[Character]

I've wrote a simple timer a while ago. (see url for zip downloads)
First I had some issues with PB-threads and later on decided to use API-timers. (thanks to Balrick)
Everything is fine except for one little thing:
When I hold down right or left mouse button located on the title bar of the window (or child window) the timer stops.
I tested same thing with another random freeware timer downloaded from the internet and that one got the same thing.
Strange thing is that when I used PB-threads I didn't see that behaviour.

Probably this is normal. Also it is not a big issue but maybe someone knows more about it or has some tips for me..
Used API:

Code: Select all

SetTimer_(WindowID(#Window_1), #Timer_2, 500, @Run_Alarm())

The threaded version (1.2) versus the API-timer version (beta):
http://riz.uwnet.nl

[Pantcho!!]

Ahhh i dont get your question

so you do want it to stop ?

if yes and you are using threads there is no event that tells the window to
stop its action

i know what you mean it is almost in any windows app while it do somthing and you move the window all stops

using threads won't cause it to stop

i suggest you that if you want it to stop

or stop using threads

or just use a simple check in your timer loop if the window is being moved
and/or the moused moved in the title area.

hope i helped.

[Character]

I assume that when I use the API-timer it is running in a kind of thread by windows. (or not?)
The point is that is seems not to be the same thing as a PB-thread.
I have tested that by running the alarm sound.

When this alarm sound is running in the PB-thread, nothing can get it down (like moving window, clicking around etc.)
When alarm sound is running in the API-timer, you can stop it by fooling around with the title-bar of the window.

I think this is related to the nature of things.
I loop in a thread isn't the same thing as a function that times out.

Sorry for the vagueness. It is so difficult to explain when you don't understand yourself...

[Character]

I've done some testing and found out that the problem can be described in 1 sentence:

"when holding down the right mouse button on top of the title bar, the timer stops running. When releasing the button, the timer continues."

Not only my program has this behaviour: I found 2 other timers on the internet with exactly the same funny thing.


3 example timers:

http://riz.uwnet.nl
http://fileforum.betanews.com/detail/Egg/1047201686/1
http://bluefive.pair.com/alarm.htm

[citystate]

just a couple of questions for clarification:

what is the desired behaviour you want from the timer -
to stop when the mouse button is down or to continue regardless?
by saying the timer stops, do you mean it pauses until you release the mouse button or does it just stop updating?

Cheers

[netmaestro]

I can't get your website, but this code keeps running:

Code: Select all

Procedure Timer(hwnd, uMsg, idEvent, dwTime)
  Static cc
  SetWindowTitle(0, "Current Timer: "+Str(cc))
  cc+1
EndProcedure


OpenWindow(0,0,0,320,240,"Timer Test",$CA0001)
SetTimer_(WindowID(0),0,1000,@Timer())

While WaitWindowEvent()<>#WM_CLOSE:Wend

[byo]

I can't get your website, but this code keeps running:

Nice!
But if you keep the RMB pressed on the titlebar it stops. Maybe because of the popup menu?

[netmaestro]

This one won't stop for either mouse button:

Code: Select all

Procedure Timer(uTimerID, uMsg, dwUser, dw1, dw2)
  Static cc
  SetWindowTitle(0, "Current Timer: "+Str(cc))
  cc+1
EndProcedure

OpenWindow(0,0,0,320,240,"Timer Test",$CA0001)
timeSetEvent_(1000, 10, @Timer(), 0, #TIME_PERIODIC)

While WaitWindowEvent()<>#WM_CLOSE:Wend

[byo]

It's amazing how a little function there can make a whole lotta difference.

[EDIT] timeSetEvent_() Undocumented in the WIN32API help file?

[Character]

Thanks netmaestro!! You helped me a lot!
(I keep on struggling with that winAPI)
Btw, do you know why this (gui)behaviour is so different?

Code: Select all

SetTimer_(WindowID(#Window_1), #Timer_1, 1000, @Run_Timer())

VS

Code: Select all

timeSetEvent_(1000, 10, @Run_Timer(), 0, #TIME_PERIODIC)

@citystate:
Thanks for the reply.
You can run the timers and test it for yourself.
It's funny, I never noticed it before.

[Dare]

Hi NetMaestro,

A couple of questions based on assumptions:

uResolution

Resolution of the timer event, in milliseconds. The resolution increases with smaller values; a resolution of 0 indicates periodic events should occur with the greatest possible accuracy. To reduce system overhead, however, you should use the maximum value appropriate for your application

I don't quite follow this.

I am assuming that this means that the timer used is the multimedia timer but I can't see how to get anything smaller than milliseconds. Are they using the more accurate time just to get the callback happening as close to the millisecond mark as possible?


Also I am assuming that TimeKillEvent is required to close the thread that TimeSetEvent starts. (So in a perfect world there would be a TimeKillEvent after the window closed in your example). Or does the closing of the window automatically kill the thread?

Thanks!