Re: Re: About Creating New Packages/Widgets & Other Dev Help

> On Dec 24, 2015, at 4:13 AM, Metallicow <[email protected]> wrote:
> 
> 
> 
> On Friday, February 7, 2014 at 3:08:06 PM UTC-6, Robin Dunn wrote:
> Metallicow wrote: 
> > SmartHighlighting Ex: if extra functionality is desired without 
> > overwriting the default handler. Im guessing event.Skip() should always 
> > be wisely placed somewhere in the event(beginning or end). 
> 
> It doesn't really matter where it is called.  It just sets a flag that 
> is checked after the event handler returns. 
> 
> -- 
> Robin Dunn 
> Software Craftsman 
> http://wxPython.org <http://wxpython.org/>
> 
> Well... Yea. I now see that it DOES really matter where event.Skip() is placed, 
> but only in instances where the code is doing *ALOT of stuff* and you want to 
> choose specifically when to call the func.
> I noticed this in very in-depth tests with my ShapedBitmapButton.
> Like you said... normally this shouldn't matter much.
> ... But it does matter sometimes... 
> ...especially in (recursive) loops and (recursive) event loops...
> ...urg... my head is spinning again...

No, it doesn't matter in terms of Skip's effect. Calling Skip does not take effect until the function calling it returns. This is 100% always true. :) But it is also true that every function call you make has a minor performance impact, even if it does nothing but set a variable, as simply calling the function does take some small amount of CPU time. So what is probably happening is that with all the recursion and loops you're running, those milliseconds are adding up and causing the subsequent calls after Skip to happen at slightly different times, like 1ms later after the first call, 2ms later after the second, etc. and soon some operations are happening a second later, or more.

When moving around inconsequential calls like event.Skip() makes a difference in app behavior, it usually indicates that there is a performance problem somewhere else in the app. Generally speaking, having lots of recursion and events firing makes things hard to debug and should be avoided if possible. I can't say much else without seeing the code, but if you've only been testing this on one machine, I'd recommend testing on other machines with significantly different specs, if you have one available, and see if your results match. That will help give you an idea of if your fix is a general purpose fix or just appears to fix the problem on a particular test machine.

Regards,

Kevin

> Thanks Robin.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.