A minor point really.
I have set restricted Idle handling in some of my applications:
wxIdleEvent::SetMode(wxIDLE_PROCESS_SPECIFIED);
For wxAUI to work in that case it needs
SetExtraStyle(wxWS_EX_PROCESS_IDLE);
in the wxFloatingPane constructor.
Since it depends on the idle processing, it may as well be added to the code.
Otherwise, great work! I've gone from FL to Dockit to AUI, with each one easier to use than before.
Jurgen.
Kirix Support Forums
OnIdle handling
2 posts
• Page 1 of 1
May I suggest to remove the use of wxIdleEvent completely (from wxAUI)?
It's not only very incompatible with programs that use this feature (together with the RequestMore event thingy), but it also makes the program (or actually wxAUI) take up 100% of the CPU time when dragging a floating panel around (or even when holding it still, but keeping the mouse button pressed). Or about 50% when using a P4 with hyperthreading.
Aside from that I really like wxAUI, though. Keep up the great work!
It's not only very incompatible with programs that use this feature (together with the RequestMore event thingy), but it also makes the program (or actually wxAUI) take up 100% of the CPU time when dragging a floating panel around (or even when holding it still, but keeping the mouse button pressed). Or about 50% when using a P4 with hyperthreading.
Aside from that I really like wxAUI, though. Keep up the great work!
- Big fan of wxAUI
2 posts
· Page 1 of 1
Return to wxAUI Patches & Modifications