On Sat, Jul 2, 2011 at 1:41 PM, <[email protected]> wrote:
> **
> I'm changing the exercises for the Guide to bring them up to date with the
> new approach for menus given the availability of the .Application class.
>
> The CustomerView exercise is an RcDialog, and now works fine having placed
>
> .Application~useGlobalConstDir("O", "CustomerView.h")
>
> at the start of the app (I assume "O" is short for "Only").
>
The 'O' is for only.
Recall, or note, or think about this: In 4.1.0, each dialog object has an
attribute (a method) called the constDir. The constDir attribute is
assigned a .directory object. The purpose of this .directory object is for
the programmer to add items to the object where the index of the item is a
symbol and the value at that index is a number. Internally, for methods
that have an argument to the method that is a resource ID, ooDialog will try
to resolve a symbolic ID by looking it up in the .directory object.
To be precise, for a method argument that is a resource ID, ooDialog checks
if the argument is a whole number. If it is, ooDialog just uses that
number. If it is not, ooDialog checks if the argument is an index in the
constDir of the object the method is invoked on, *and* the value at that
index is a whole number. If both conditions hold, then the number at the
index is taken to be the resource ID. If not, the method fails.
This mechanism is completely unchanged by default in ooDialog 4.2.0.
Now in 4.2.0 a global constant directory is added (.constDir). It is an
enhancement and how it is used is left up to the programmer. By default, it
is Never used.
The programmer changes the way the global .constDir is used through the
application object's useGlobalConstDir() method. The first argument
specifies how to use the global .constDir. The value of the argument can be
Never, First, Last, or Only. Only the first letter of the value is needed
and case is not significant.
First and Last indicate use the global .constDir *in addition to* the
object's constDir attribute. For this usage, when a symbol needs resolving,
both constDir objects are searched. Either the global constDir is searched
first, or it is searched last.
The 'Only' value optimizes this whole process. It only looks at the global
.constDir. In addition the whole lookup process is also optimized.
However, part of the optimization makes the symbol look up case sensitive.
Some people may see that as a drawback to using the global .constDir.
Another drawback could be that the global .constDir is global to the
application. Which means that duplicate symbols with different numeric
values can not be used. I.e., if you have dialog A with symbol IDD_DIALOG1
== 100 and dialog B with symbol IDD_DIAOLG1 == 200, this will not work using
the global .constDir. (Or rather you could do it, but you outcome is
indeterminate.)
The second argument to useGlobalConstDir() is a convenience argument:
.Application~useGlobalConstDir("O", "CustomerView.h")
It can be the name of a file that defines symbols and their numeric value.
I.e., each line of the format:
#define x n
that is found in the file adds an item to the global .constDir whose index
is 'x' and value at that index is 'n', where 'n' must be a whole number.
Items can be added to the global .constDir in other ways that would add
items to a .directory object. For example:
.constDir['IDD_DLG_1'] = 100
.constDir['IDD_DLG_2'] = 150
In the future another method will be added to the ApplicationManager class
with the tenative name of addSymbols() that will also add items to the
global .constDir.
There, that should be the complete documentation for the global .constDir
object. Probably with more explanation than the docs will have. <grin>
> However, if I delete the .Application statement and replace the symbolic ID
> in .ScriptMenuBar~new with a numeric ID, it does not work.
>
On the face of it that would be a bug. Numeric IDs should always work. As
I explained above, if the argument is a number, it is just used. The
constDir objects do not come into play at all in that case. Please send me
your program so I can debug it.
> Would this have anything to do with my use of dlgData in the ~new fopr the
> dialog, which is still:
>
> dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData.,
> "customerView.h")
>
>
No, it wouldn't have anything to do with that. (Shouldn't, it still could
be a bug.)
>
> However, ProductView, a ResDialog, works fine either way.
>
> I'm trying to understand the new rules for each of RcDialog and ResDialog
> since they differ. So several questions arise:
>
No the rules are not different. There is some type of misunderstanding
here. (Maybe mine, maybe I don't really understand what you mean.)
>
> (1) For RcDialogs, can they work without using the .Application approach?
> and still get menus working OK? I tried using the numeric ID without the
> .Application, but it barfed. Was it my inclusion of dlgData?
>
>
Yes, yes, and no.
dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData.,
"customerView.h")
(Question 1 above) If this works in a program under 4.1.0, and you don't add
anything to that program, it will work under 4.2.0.
(Question 2 above) You can use the menu classes in your program under 4.2.0
and they will work fine. (Remember the menu classes do not exist in
4.1.0.) If you use numeric IDs in your menus, menus will work fine. If you
want to use symbolic IDs in the menus, you will both need to use the global
.constDir *and* add those symbols to the global .constDir.
There a number of ways of meeting that stipulation. With the explanation
above, you would need to decide what will work best for your program and
coding style. I don't know where you have the menu symbols defined for the
example we are talking about now, but say they are in 'menu.h' Then this
would work:
.Application~useGlobalConstDir("L", "menu.h")
dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData.,
"customerView.h")
This will work if they are in customerView.h
.Application~useGlobalConstDir("L", "customer.h")
dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData.,
"customerView.h")
> (2) Suppose I have two different in an app, each in a separate file, and of
> course each with different .h files. How would I use .Application to provide
> resolution for two (or more) .h files?
>
>
Personally, I would always put all the defines for a single application in
the same file, but there are reasons for putting them in separate files.
You would use the tentatively named addSymbols() method. Right now you
could also use the undocumented parseIncludeFile() method. But, I probably
will not document that method, meaning that it could go away, or be changed
in the future.
.Application~useGlobalConstDir("L", "customer.h")
.Application~parseIncludeFile("menu.h")
The above should really be:
.Application~useGlobalConstDir("L", "customer.h")
.Application~addSymbols("menu.h")
or addToConstDir(). Or something similar.
--
Mark Miesfeld
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Oorexx-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-users
