Re: [Wxlua-users] ControlDown?

[The D. <the...@bl...>]

John Labenski <jla...@gm...> wrote:
(22/07/2005 23:14)

>
>local r = toolBar:GetRect() 
>print(r:GetX(), r:GetY(), r:GetRight(), r:GetBottom())
>
>as well as the mouse event you get. Maybe that will help make sense of
>it? Also use toolBar:GetToolSize(). Finally the position you're using
>is in pixels so you should use y = toolheight/2 and x = toolwidth/2 to
>guarantee you're actually on a button, x = 0 might be your problem.
>

I worked out the tool position, and the no-go areas. 0 is no problem, but it is possible to overshoot vertically by one pixel into the blank toolbar space... Anyway, FindToolForPosition() doesn't have any of those problems, and getting the rects wouldn't help if the code hadn't identified which tool I was pointing at. :) It was an oversight of mine though, as I showed in the third of yesterday's mails, I just used GetX() and GetY() to get co-ords in the right format.


>Hopefully, once you get used to it it'll make more sense. wxWidgets is
>a complicated system and since it uses native controls, it has to work
>around bugs and oddities with them finding a happy middle ground. I
>think it does well, but it takes some getting used to.

Agreed. It does do very well. It's stable, and I trust it. I like that it is possible to work round things and get a consistent result. I hope my own thing with the toolbar script has tied into this nicely. It appears to be ok, as it uses things already built in to wxLua to overcome obstacles. What I value most is having a way of working that remains consistent and powerful, and I'll go a long way out of range to get that, so that later I can use the modularised results.

To whoever it was that decided to incorporate FindToolForPosition() into wxLua, thankyou, as that is a great example of a single function allowing a huge advance in overcoming problems accessing tools. Having looked at the options that were not included in wxLua (like FindById()), I came to see that if any single one be chosen and none of the others that might help, this one is by far the most useful. A good choice.

>
>Toolbar tools are NOT real windows and do not have the same
>functionality as a wxWindow (again that's why I suggest using
>buttons). When I say they're a black hole, it's because it's that way
>in MSW and GTK. Both widget sets have almost no capability to do the
>things you want. They're some sort of container that probably draws
>the tools itself and they didn't bother to write functions to get at
>where they're drawn. Therefore wxWidgets doesn't have them either. I
>hate it too and have tried many times to work around it, eventually I
>give up and use a button (usually combobox) and then knowing where
>that is, figure out where the other tools are.
>

ok :) I solved what I needed to solve though. I knew there were limits, that they are not real windows, but I knew that there should be a way past that particular limit, and it turned out to be so. In this case it was using code that could find the tool and recover it's ID if the pointer was sitting on it. I'll try to seperate single from double clicks too, maybe, but I'll have to investigate some kind of timer for that, as time is the the only thing that truly seperates them, as no double click can occur without generating a button-up or button-down event... Not important though, I have more than enough possible controls branching off a single tool now. >:)

Thanks for your help, it beats having to do it all alone.

Crow.