On Mon, Nov 12, 2012 at 1:17 PM, <Amphitryon@ok.de> wrote:

> The answer is that the code in the reference manual is just a
> snippet of code.  The sysMenu object is used in other places in
> the complete program.

In the manual are many examples what helps a lot. To make
modifications to test something I copy-paste such examples to a
.rex file just to find out it is only a snippet that does not run
as is. For me as novice that is hindering,


The ooDialog extension comes with a large number of complete programs to use as examples.  ooDialog 4.2.0 has 117 complete example programs.  The next version, ooDialog 4.2.1, has 150 complete example programs.  You should take advantage of those examples if you want complete programs instead of code snippets.

With ooREXX I have to add so many corrections to that model:
directives, objects, classes, a whole zoo. And now a global
constDir and a not so global constDir (becoming obsolete).

The mechanism that allows the use of symbolic IDs in an ooDialog program is meant to be a convenience for the programmer.  If you find it a hindrance, then don't use it.

All dialogs, dialog controls, menus, menu items, and a large number of other "things" used by the windowing system in Windows are required by the operating system to have an unique numeric ID.  This is not something that is imposed upon you by ooDialog.  ooDialog allows you to use symbolic IDs instead of the raw numeric value, but it doesn't force you to do that.  By all means use the raw numeric numbers instead if that suits you.


I looked again through the ooREXX Programming Guide and the ooREXX
Refference to find something to help me build my model. Best up to
now is Chapter 1 'Open Object Rexx General Concepts' in 'ooRexx
Reference Version 4.1.2'. Is there somewhere a description what
happens when I start a ooREXX program from the command line?


I don't see that it is any different than any other Rexx interpreter.  When you start an ooRexx program from the command line, the interpreter parses the Rexx code in the program and starts executing it clause by clause.

 
>
>  .application~useGlobalConstDir('O')
>
>  .constDir[IDC_EDIT]      = 100
>  .constDir[IDC_PB_WRITE]  = 100

That is a typo on my part, numeric IDs need to be unique.  Should have been 100 and 101, or any other 2 unique numbers.
 
>  .constDir[IDM_PASTE]     = 64
>  .constDir[IDM_COPY]      = 80
>  .constDir[IDM_CUT]       = 96
>  .constDir[IDM_MENU_EDIT] = 301
>  .constDir[IDM_SEPARATOR] = 305

The designation of the symbolic ID is free, I assume. Or has it
some meaning to ooREXX that all start by 'IDM_' or 'IDC_'?

You can use any symbol name you want.  I use a naming system that makes sense to me, so that the symbol name has meaning for myself.  IDC is id of a dialog control, IDM is id of a menu item.  You can, and should, use some naming system that makes sense you.

 
And why
all uppercase? Just aesthetic? And there may happen variable
substitution? Would it be a good practice ot code
.constDir["IDC_EDIT"] = 100

The .constDir object is a Directory.  Indexes in a Directory are case sensitive.  By not quoting the index I know that it will be all upper-cased by the interpreter and I don't need to worry about case sensitivity if I always use the symbol name unquoted.  I would never, ever, ever, name a variable in any of my Rexx code that started out IDC_ so I don't need to worry about variable substitution.

This works very well for me, so I use it consistently.  Example code I write will all use my conventions.  

You should probably use whatever conventions and coding style makes sense to you.  Be aware of the case sensitivity of the Directory indexes.

 
> The .application object is documented in the Utility Classes and
> Objects section in the reference manual.  As you probably saw
> from your previous question, the symbolic IDs in the constDir
> need to be present before your program uses them.

As such I did set them in the ::method init section.

But that's a mistake, as I pointed out.  If you want to put the setting of the symbolic names in the init() method then you would need to set them before you invoked the create() method.  The create() method causes the defineDialog() method to be invoked and in the defineDialog() method you used the symbolic IDs.  If you set the symbolic names after the create() method, then you use the symbols before you set them.

--
Mark Miesfeld