Hello Mark!
> I just wanted to point out a few things about symbolic IDs from
> your example code. In addition, you had this question in the
> code:
>
> expose sysMenu /* why is sysMenu exposed? It is only used here */
>
> 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, but I understand that
complete programs woud not focus on the example's subject.
> Regarding symbolic IDs. Symbolic IDs work well once you
> understand the details.
I assume it worked the same way before I knew that detail. But I
may use it in future with advantage.
> The original ooDialog implementation
> used the constDir attribute of a dialog. This was a rather
> limiting choice. Not everything is a dialog. When I started
> adding enhancements this short coming became apparent. Menus,
> resource images, etc.. are not dialogs. So, the original
> concept was extended to what is called the global constDir.
All is complicated the first time. As a novice I try to make a
model of what happens behind the scene. Then I work with that
model (what gets some corrections with the time). For REXX that
model is quite simple: you have a file with code that is
interpreted clause after clause, the interpreter keeps a variable
pool that may be hidden from subroutines (procedure) or shown
partially (expose). And every routine should set the return code
adequate if there was an error or not (as should all system
routines). A coarse picture.
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). In
contrast Mike Cowlishaw's REXX was just 'a flock' of commands. Of
cause to compare REXX with ooREXX that way is not fair as ooREXX
has an other objective.
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?
> All new code should use the global constDir. For one thing, it
> has a far more efficient look up mechanism. To use symbolic
> IDs in menus, resource images, and other possible new classes
> that are not dialogs, you *must* use the global constDir. The
> program you posted would be better off by starting it this way:
>
> .application~useGlobalConstDir('O')
>
> .constDir[IDC_EDIT] = 100
> .constDir[IDC_PB_WRITE] = 100
> .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_'? 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 .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.
> Here is a rework of the entire program that should work fine
> for you:
> [...]
Wow! Thank you. If it turns out that I will do more than 2 ooREXX
programs using ooDialog I will use it as starting point to make a
nice template.
Thank you for this global constDir lesson.
Best,
M.
--------------------------------------------
Kostenlose E-Mail-Adresse mit unbegrenztem Speicherplatz für E-Mails, Free SMS
und OK-Drive, der Online-Festplatte.
Sicher Dir jetzt Deine Wunschadresse @ OK.de: www.ok.de
------------------------------------------------------------------------------
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
