On Mon, Nov 12, 2012 at 1:17 PM, <amphitr...@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
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users

Reply via email to