Re: [Wxlua-users] ControlDown?

[John L. <jla...@gm...>]

On 7/22/05, The Doctor <the...@bl...> wrote:
> Hi John, I have an answer, of sorts, having made FindToolForPosition() wo=
rk...
>=20
> TBAR:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
>     function(EV)  ID=3DTBAR:FindToolForPosition(0,1):GetId()  if (EV:Cont=
rolDown()) then  DoThings(ID)  end  EV:Skip()  end
> )
>=20
> This will detect the first tool, but is no better than manually specifyin=
g the ID. I'd also have to test for the presence of the tool before trying =
to GetId(), or there would be error. That's easy but what I really want is =
TBAR:FindToolForPosition(EV:GetPosition()). That would allow a single handl=
er and a single function called by it, to handle any tool, and any state fo=
r Ctrl or Shift or Alt keys while clicking it with either mouse button.
>=20
> The only thing stopping me from getting at this wonderful power is the mi=
nd-numbingly annoying incompatibility in the way co-ordinates are handled.
>=20
> Surely it's not too much to expect that GetPosition() can return co-ordin=
ates in a form that FindToolForPosition() can use?! I guess it is though. I=
s there a way to convert?

I haven't tried this at all, you can print out the rects of the
different things. Starting with

local r =3D toolBar:GetRect()=20
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 =3D toolheight/2 and x =3D toolwidth/2 to
guarantee you're actually on a button, x =3D 0 might be your problem.

> It's things like this that keep me slow and asking confusing questions. T=
he trouble with wxWidgets, (or wxLua, I'm not quite sure which) is that unl=
ike Lua itself, so much is done with specific behaviours that don't seem to=
 talk well to each other, except via black boxes whose behaviour alone is a=
ll I have to go on to understand them.=20

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.

>In Lua, the emphasis is on a simple versatile system that can be
adapted to many ways of working. This is partway possible with wxLua
too, but the most versatile forms seem to involve catching mouse
events, but I keep being thwarted with proplems like lack of
propagation, or mismatches in co-ordinate handling methods, or
problems getting ID's for things, of finding those things to be
userdata and finding no way to know what exactly that userdata is.

We can write a method to print the userdata type I think. That would
definitely be handy. In addition to that I think it should be easily
possible to generate info about what's wrapped for each control from
the c++ side and somehow make this printable in lua.

> To illustrate that last point, I can do this:
>=20
> ID=3DTBAR:FindToolForPosition(0,1):GetId()
>=20
> Which seems to imply that TBAR:FindToolForPosition(0,1) will point to the=
 actual tool.
> If it did, I could do this:
>=20
> X=3DTBAR:FindToolForPosition(0,1)
> X:ConnectEvent(-1,wx.wxEVT_LEFT_UP,
>     function(EV)  stuff...  end
> )
>=20
> This won't go. ConnectEvent is invalid in this case. Whatever X is, it's =
not the tool! And I have no way to know what it is.

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.

Regards,
    John Labenski