Re: [Oorexx-devel] Comments on these new ooDialog methods

[Bill T. W. <wb...@ar...>]

Mark, like Rick I prefer the easy to remember words as opposed to long 
argument lists.

To maintain compatability, however, additions must not change what is 
already there..
 (I, like most, do not like having to go back and rewrite working 
software just so I can "upgrade" and use newer features...

I do have a pet pieve, however, in that some of the existing code is not 
always consistant in its coding format.

Many of the ADDxxx methods currently in use have similar parm lists - 
but they are sometimes in a different order.
This makes it hard for a starting programmer, and it makes it very 
difficult  to use the code to help document how an ooDialog form is 
really designed.

In particular the "ID", "name", "X", "Y", "CX" and "CY" values are not 
always in the same place or sequence - sometimes the ID is first - 
sometimes it's last, sometimes, you can name things, sometimes you 
can't, etc. I think I would even have accepted required "missing" parms 
just to get these six fields in the same sequence. (I.e. you are 
required to code " ,, " because your not allowed to define an "id:" for 
example.

We also have a bunch of inconsistancies for the beginner.  We do 
"EditControls" but define "AddEntryLine"  On the other hand, we do 
"listControls" and we "AddListBox" - and the same is true with the 
ComboBox.  Most methods that work on a similar object have similar 
names, but this is not always true.

While I was getting started,  I found many references to "Edit boxes" 
but there was no "AddEditBox" and it took forever to discover than an 
"entryline"  (read entryLINE) was the same as an "editBOX".  (I'm not 
sure where I saw the "editbox" refernce - I can't find it now.)  Like I 
said, many _do_ have similar names, like ComboBox, ListBox, etc. -- but  
where did "entryLINE" come from?

- - -

As an aside I am still having much trouble getting some of the advanced 
controls to work ALL OF THE TIME. (It has to be my code, but the doc is 
NOT clear on how to define "things" and in what sequence and when do you 
use "connect" controls such that the Rexx Object and the Windows Object 
stay in sync when doing ooDialog things - changing focus, discovering 
when focus has changed, learning why a method gets re-invoked when you 
try to change the background color in response to data contents of TWO 
or more fields, etc.  It is also not clear where you should actually 
code some of the Advanced/message extension stuff.  When you  put it in 
"method INIT"  and when do you put it in "Method DefineDialog" or 
"Method Run"  --- and just where the heck do you find out that these 
even exist? 

I've hacked some of my code to make it work - but the examples are not 
real good for somebody who wants routine that just does a bunch of "data 
entry" and loads a database with "error checked data". Or that displays 
data in a more dynamic manner.  (I dont like to open and close "pop" 
menus  - its distracting while typing, but apparently that was an early 
model used when defining ooDialog.)

The documentation is not very clear to an ooDialog  _beginner_ how to 
get things going.  Got any examples for data entry as opposed to fancy 
animated displays?

Second question? Is it possible under Windows to use a "fuller" pallete 
of colors - (many more than "16".)
I realize that this becomes an operating system specific item 
(compatability issues between Linux and Windoze), but could something be 
added to ooWIN32?
Or have I not found it yet?

I would like to answer more specicically to your originial questions - 
but I'm rather tapped for time at the moment, and I still classify 
myself as a "beginner" - so I'm not sure that I fully understand all of 
the issues yet.

However, your "not condensed" methods were very clear to me with regards 
to purpose and intent.  (I did not like the "-1" in the examples - I 
wasn't really sure what it was trying to indicate.)

I think we need to remember that the majority of expense in 
"programming" is during maintenance of the code.  Have the ability to 
"self document" is very important in my book and probably comes from 
having spent thousands of hours at 3am in the morning figuring out what 
"the intent was"  in somebody else's program.... (But then that is why I 
did get called in at 3am, because I COULD debug the "other guys" stuff - 
especially when they were no longer available... I think the only reason 
that I did _not_ hear was "being hit by a Bus!") 
 
I don't mind a "little" longer development time, if the maintenance 
becomes easier - and especially if the program runs a little more "error 
free" because the commands were easy to understand

later...

/s/ Bill Turner, wb4alm




Functions that are added should be added as a "system" so that 
constructions that can be the same are the same.


Rick McGuire wrote: