Todays work will be to try PushEventHandler instead of SetEventHandler, as I read that it was preferred. I just stayed with what appeared to work so far, and also to test what was possible. :)
The override of the button left click was just a matter of testing, I got it with event:Skip() before my own call, placed in the EVT_LEFT_UP handler. I removed the original BUTTON_CLICKED handler... This probably won't be my final answer; I was considering the StaticText, but that won't take a colour change so it can't be used as an indicator. Disabling is not an option, as I need the control to be enabled regardless of its state. I'm just trying stuff to see what can work, before I settle on the best choice.
About the LEFT_UP before DCLICK, I agree, I overlooked for a moment that LEFT_UP must always be detected during a DCLICK, and there seems to be no way to separate them. In this case it will be acceptable though, as the stuff ordered by LEFT_UP is small, fast, and there is no harm in it being done also when DCLICK orders its own stuff. I'll try to separate the orders some time, but it's not a high priority now.
Your point about being pleasantly surprised if a wxButton gives a LEFT_DOWN is exactly the same sort of thing that drove me to this experiment. I want to find a reliable way to get any kind of click I might want from a control. That way I can make more events from one control. It makes motor memory play a bigger part instead of the current high reliance on visual memory. Doing this increases the ease and efficiency of moderately complex user operations, as well as allowing only those methods required to do the task. For example: in my taks I want a control to do a data copy on left click, to toggle a state with double-click, indicating said state on the same control, and to popup a menu of paste options with the right click, all on the same control. I have achieved this, but not yet found the best way, no doubt... I was partly hampered by the alternate bitmaps and toggling not working in wxLua toolbar buttons. :) This made me look for other options... I've now decided that I want this rather badly, the idea of being able to use any or all kinds of mouse click for a single control of many or even all types, is so powerful, to me it makes sense that it should be possible, easily overriding a default behaviour where needed.
Btw, about FRAME:Close(), I remember why I didn't keep it that way now. I tried it again after your mail. I have a handler to catch any attemt to close the frame. It does stuff, then FRAME:Destroy(), cos FRAME:Close() in that handler makes a loop until some stack overflows. :) If there is a better way to avoid that loop, please let me know.
> It would be best to simply call a common function
> to handle the event for all windows if this is what you really want.
It is. But that's the problem. For SpinCtrl's I do this easily, I just use FRAME:ConnectEvent() for wxEVT_COMMAND_SPINCTRL_UPDATED to catch them all and call a function that processes according to ID. This works cos the COMMAND events propagate right back to the frame. While the mouse LEFT_UP, DCLICK and such do not propagate, I have to catch each control I want to click by using a handler for each one, each handler calling the common function. That's a lot of code, even for 3 groups of 6 buttons on separate notebook pages. If I could make some tiny, hidden control with no events of its own, say a StaticText of zero display size, I could make all the click events get handled by that. I'd still have to direct the handling from each real control, but at least the code to do it is very small and neat.
I guess what I'll do is turn over the Thinger before it's complete, so you can see what is being done. I just want to make sure it works as intended, so that the behaviour as seen by the user is clear, and then any code corrections will be easier to do, as there will be a working precedent for what it has to do. Having got the main idea for Operator parameter copying and output enabling sussed (or at least doable), it shouldn't be long now. I suspect a lot will be better changed, but I think we'll get more out of it this way. I'll learn more easily about better coding from modifications to work I've already done, and you'll see an idea that might make some interesting ways to do things, and one that demonstrates what I feel is a need for easier customising of control handling.
|