kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/13/2013 08:03 AM, Dick Hollenbeck wrote:
> On 08/13/2013 07:09 AM, Dick Hollenbeck wrote:
>>>
>>> I find track laying impossible without mouse warping... there is an
>>> option to disable it. But how could you *emulate* it, if there is no way
>>> to physically move the pointer? 
>>
>>
>> The OS+native windowing system will move the mouse coordinates in the next mouse move event.
>>
>> Your tool, if pushed onto the wxEvtHandler stack, I am thinking should have first access
>> to ALL events, (~captured mouse) so as long as you retain state information the next call
>> to ProcessEvent(), possibly routed to TOOL::OnMouseMove(), you can/could in there redraw
>> the mouse cursor at the new desired location, or not.
>>
>> See wxEventLoopBase in http://docs.wxwidgets.org/trunk/classwx_event_loop_base.html
>>
>> This class sucks events out of the os queue, and gets first dibs on any events, it is the
>> first recipient of any OS events when it is alive, and dispatching happens from here.
>>
>>
>> If simply residing topmost on the wxEvtHandler stack does not give you enough control,
>> then there is the option to create another wxEventLoopBase temporarily.
>>
>>
> 
> 
> Here are some nice graphics and explanation of PushEventHandler:
> 
> http://docs.wxwidgets.org/trunk/classwx_window.html#a398c11ab9af7956067a964f560d1978c
> 
> It is my thinking that putting this in the wxFrame, by calling its PushEventHandler will
> give you first dibs on all events. 



That was a guess.  Probably time to stop guessing and write some test code, and examine
the source.



>If you follow the wEvent::Skip() protocol, and not
> process events not pertinent to you, and I think this means knowing the client window area
> coord and checking mouse events against that box, then any wxEvent can still find its way
> to its normal destination outside the tool.
> 
>