onmove and setposition

I was setting up a "main" window with several dialogs with the main
window 
as their parent and wanted them to move when the main window did.
I note wxwindowvar.onmove fires an incremental number of times with movement 
of wxwindowvar. This would be good for simultaneous smooth movement of any 
other associated windows but this doesn't happen until the left mouse is 
released so the "main" window moves and then associated
windows/dialogs move 
only on release of the left mouse button.

wxwindowvar.setposition works flawlessly across my extended desktop to the 
right/second monitor but wxwindowvar.onmove reports window.left when off the 
left of screen as minus x
however, wxwindowvar.setposition gives a "number out of range" if
using the 
same x value
eg.
x = wxwindowvar.left
//if x < 0 the following statement returns "number out of range"
wxwindowvar.setposition(left = x)

Is this a bug?
John 

"John Roberts" <remjohnr@iinet.net.au> wrote in message 
news:facapr$9no$1@ipx22096.ipxserver.de...
>I was setting up a "main" window with several dialogs with the
main window 
>as their parent and wanted them to move when the main window did.
> I note wxwindowvar.onmove fires an incremental number of times with 
> movement of wxwindowvar. This would be good for simultaneous smooth 
> movement of any other associated windows but this doesn't happen until the

> left mouse is released so the "main" window moves and then
associated 
> windows/dialogs move only on release of the left mouse button.

This repeated onresize event behaviour also means is that if a form is 
scaled in its window resize event, it is rescaled repeatedly on left mouse 
release. This is ok with a small number of form controls but may slow things 
with a larger count.
John 

John Roberts wrote:
> "John Roberts" <remjohnr@iinet.net.au> wrote in message 
> news:facapr$9no$1@ipx22096.ipxserver.de...
>> I was setting up a "main" window with several dialogs with
the main window 
>> as their parent and wanted them to move when the main window did.
>> I note wxwindowvar.onmove fires an incremental number of times with 
>> movement of wxwindowvar. This would be good for simultaneous smooth 
>> movement of any other associated windows but this doesn't happen until
the 
>> left mouse is released so the "main" window moves and then
associated 
>> windows/dialogs move only on release of the left mouse button.
> 
> This repeated onresize event behaviour also means is that if a form is 
> scaled in its window resize event, it is rescaled repeatedly on left mouse

> release. This is ok with a small number of form controls but may slow
things 
> with a larger count.

This is because of the fact that if Windows has the eye-candy turned on
specifically the option "show window contents while dragging" (it is
by
default in XP) then your are getting a lot of events continually sent
rather than just one when the user lets go. One way to handle that might
be to check and see if the mouse has been released and if not, wait
until it has been before handling the event.

"Neil Robinson" <neil@simpol.com> wrote in message 
news:fbh21b$hjt$1@ipx22096.ipxserver.de...
> John Roberts wrote:
>> "John Roberts" <remjohnr@iinet.net.au> wrote in
message
>> news:facapr$9no$1@ipx22096.ipxserver.de...
>>> I was setting up a "main" window with several dialogs
with the main 
>>> window
>>> as their parent and wanted them to move when the main window did.
>>> I note wxwindowvar.onmove fires an incremental number of times
with
>>> movement of wxwindowvar. This would be good for simultaneous
smooth
>>> movement of any other associated windows but this doesn't happen
until 
>>> the
>>> left mouse is released so the "main" window moves and
then associated
>>> windows/dialogs move only on release of the left mouse button.
>>
>> This repeated onresize event behaviour also means is that if a form is
>> scaled in its window resize event, it is rescaled repeatedly on left 
>> mouse
>> release. This is ok with a small number of form controls but may slow 
>> things
>> with a larger count.
>
> This is because of the fact that if Windows has the eye-candy turned on
> specifically the option "show window contents while dragging" (it
is by
> default in XP) then your are getting a lot of events continually sent
> rather than just one when the user lets go. One way to handle that might
> be to check and see if the mouse has been released and if not, wait
> until it has been before handling the event.
>
> Ciao, Neil

Aha! Eye candy. I think these are queued and only fire when the left mouse 
is released so that may not be the answer.

What about my original question in this thread with negative left window 
positions?
John 

John Roberts wrote:
> Aha! Eye candy. I think these are queued and only fire when the left mouse

> is released so that may not be the answer.

No, they get fired continually unless you turn off this feature.

> What about my original question in this thread with negative left window 
> positions?

Tested today, and fixed. Both in setposition() and in .new()