Re: [Wxlua-users] Extended Toolbar, a new example of wxLua code.

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

On 7/23/05, The Doctor <the...@bl...> wrote:
> >Thanks, the samples probably need to be cleaned up a bit. Nothing
> >special, just make them have the same coding style and demo a couple
> >more things. I'll add parts of this once we get the c++ side going
> >again.
>=20
> Why use parts of it and not the whole? I'd like it used as it is, or near=
 enough, as I solved several significant obstacles to handling tools on a t=
oolbar, which as you say, don't behave as ordinary windows do. My coding st=
yle is not standard, but it's consistent, compact and efficient, and even t=
hat's secondary to to the content.

Well, stuff like this should be changed, you're passing the event
which you call "Z" ? and then take that variable and overwrite it with
the tool from FindToolForPosition then proceed to overwrite it with
the numeric window id of the tool and return Z (the variable that was
passed in originally?). It's easy to get confused by this, you're
returning an event? or a tool? or a window id? Have typos been made?
Who knows?

function FindTool(Z)
   Z=3DTBAR:FindToolForPosition(Z:GetX(),Z:GetY())    =20
   if Z then  Z=3DZ:GetId()  end  return Z                       =20
end
=20
I think that people will get a better understanding and learn quicker
from code written like this. The variables have names that tell you
exactly what you expect them to contain. The function takes a toolBar
and a mouseEvent and returns a window id or nil on failure. It
documents itself, even telling you what the FindToolForPosition
returns so the reader doesn't have to look it up.

function FindTool(toolBar, mouseEvent)
   local toolBarTool =3D
toolBar:FindToolForPosition(mouseEvent:GetX(),mouseEvent:GetY())
   local win_id =3D nil
   if toolBarTool then  win_id =3D toolBarTool:GetId() end =20
   return win_id
end

> In the samples, where there is a significant original work to demonstrate=
 features of wxLua, there is an intact script with the credit of the author=
 intact in it. I'd like mine to be treated the same way. What about having =
a second directory of samples from users, left entirely intact, on a caveat=
 emptor basis? :) That way I get full credit, at least somewhere in the dis=
tribution, for my help for it, and others can learn from it as I learned fo=
r myself, from whatever intact examples I find. Sometimes it's better to se=
e various sources, rather than one central interpretation. This helped me i=
n JavaScript, and the same probably applies to wxLua. If nothing else, if y=
ou do this, any eccentricity or flaw in the code will be solely credited to=
 me, as well as any merit.

Sure we can give you credit, but we want a minimal set of programs
that 1) demo wxLua features, 2) teach how to write clean, robust wxLua
code, 3) stress test the library, and 4) are easy to understand.
Remember that every bit of code has to be maintained and checked, even
now some of the samples don't work properly. I really don't want to
discourage you, the sample program is fine, it shows a lot, but took
me bit to understand it.

Regards,
    John Labenski