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

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

John Labenski <jla...@gm...> wrote:
(26/07/2005 04:56)

>> 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 toolbar, which as you say, don't behave as ordinary windows do. My coding style is not standard, but it's consistent, compact and efficient, and even that'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=TBAR:FindToolForPosition(Z:GetX(),Z:GetY())     
>>   if Z then  Z=Z:GetId()  end  return Z                        
>>end
>> 


That's just a different style. :) It's confusing without familiar context, I guess, but it serves two main purposes this way. One is the reuse of a single variable, which saves space on the page as well as in RAM, which though not as vital as it is when programming a Psion Organiser II XP in OPL, is still a very good habit to keep. The second I find more important, the use of a single arbitrary letter, and a single variable, immediately signifies that only one entity is being handled at a time, processed in stages for return. I guess I could have made a comment that the incoming item is an event, but the calling code makes that clear anyway. I take your point that the variable names could be self-commenting, but I decided the function names wxLua provided went a long way to doing just that. :)

When I need globals I have a different system. I usually use two, three, or four letters, abbreviations or acronyms usually, or consonant phonetic shorthands, chosen carefully for unique unambiguous use, like TBAR will always mean toolbar, MBAR always menubar, SBAR always status bar... Either way I'll usually declare them all in a group near the top of the page, so it's a sort of glossary.

As to what that function returns, I commented that fully, I decided I found the use of a right-hand column for comments to be clearer than mixing them with the code. I try to stick to a line for line relation, so a comment usually relates to the code on the same line. That allows for very detailed narrative, a bit like ball by ball commentary in cricket. :) It's flawed, and I'm developing the trick as I work, but I like it this way.

>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 =
>toolBar:FindToolForPosition(mouseEvent:GetX(),mouseEvent:GetY())
>   local win_id = nil
>   if toolBarTool then  win_id = toolBarTool:GetId() end  
>   return win_id
>end
>

Again, I do see your point, but to me, this is actually very confusing. The reason is that when faced with a new system I'm always struggiling with code like this. I have to thrash around trying to work out which are user variable names, and which are function names for built-in stuff. The stuff I learned from was old BASIC and OPL stuff, and the idea there was to use as few variables as possible, to reuse where you can, especially locally within a function, and to use single letters, or names that are obviously related to the users purpose, in no way confusable with existing function names. I also tend to use capitals for variables, again to distinguish them from inbuilt function names, which rarely used caps, then or now.


>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.

No problem. :) I'm not discouraged, quite the reverse, I'm glad you took the time to go through it. I'm just trying to find a way to please us both. My idea is that you take freely what you want, after all I don't own any rights to stop good use of code, and that way you can use it as you want, but at same time, keep the original in the caveat emptor box for people to see in original form. If you take a whole working chunk and re-write it, maybe add a one-line comment to say that it's reworked from script xyz.lua in the user submissions directory, so people can see it written both ways. Some will find your way easier, others will find mine so, and seeing both is surely the best of both worlds. :)

Crow.