$202 oddness

Hi, it would really help me if you could try the small program below and do the following.

1) click on the red square and keep the mouse button down. 2) Move the mouse to the blue square and let go of the mouse.

Why does eventsource() contain the handle for the red square when letting go of the mouse (the $202 action) happened over the blue square?

Is this a bug or what is expected.
Also, why doesn't $206 work while the mouse button is down?

Thanks a lot!

Global mainwindow=CreateWindow( "$202",50,50,500,300,main,3)

canvas1=CreateCanvas(50,50,100,100,mainwindow)
SetBuffer CanvasBuffer(canvas1):ClsColor 255,0,0:Cls:FlipCanvas canvas1

canvas2=CreateCanvas(350,50,100,100,mainwindow)
SetBuffer CanvasBuffer(canvas2):ClsColor 0,0,255:Cls:FlipCanvas canvas2

While WaitEvent(1)<>$803

	If EventID()=$202
	
		If EventSource()=canvas1 Then Notify "Red Canvas"
		
		If EventSource()=canvas2 Then Notify "Blue Canvas"
	
	EndIf

Wend
End

It's like mouse events are queued until the click is released. Insert this code into your loop too and observe...

If EventID()=$206
	If EventSource()=canvas1 Then Notify "Leaving Red Canvas"		
	If EventSource()=canvas2 Then Notify "Leaving Blue Canvas"	
EndIf

$203 is being reported though. Is Blitz or Win32 the culprit?

Thanks for the reply POH, i've seen the sort of pipelining of events using

debuglog hex(peekevent())

$202 is generated when the mouse button is released over a canvas and eventsource() holds the canvas handle. We're agreed on that right?

But.... Eventsource() contains the wrong canvas handle. Or does it? If I release the mouse over the blue canvas then eventsource should contain the handle for the blue canvas, right?

Either it's a bug or the documentation is wrong.

Anyway, I've worked round it by looking at the queue with Peekevent.

It's funny, I was looking at Peekevent the other day and thinking, I'll never use that.