Many thanks, Mark. I don't particularly want to use symbolic IDs, so after
reading the tracker item, I tried is with a numeric ID. It still barfs:

D:\Development\...>TestResdialogCommentless
init() result: 0
Creating menu bar
    27 *-* menuBar = .BinaryMenuBar~new(self, 107, self, , .true, .true)
  8347 *-*   self~initDialog
  7443 *-* if self~startIt(icon, modeless) \= 0
    20 *-* self~execute("SHOWTOP")
    70 *-* dlg~activate                         -- Must be the last
statement.
     1 *-* call startProductView                -- a routine in
ProductView.rex
Error 88 running D:\Development\oodUserGuide\From
Mark\TestResDialogCommentless.
rex line 27:  Invalid argument
Error 88.916:  Argument 2 must be one of a valid numeric or symbolic
resource ID
; found "a PRODUCTVIEW"
In unInit() of MenuBar class 

The error message suggests that the "107" is an instance of the class
ProductView.

Sorry, I'm still stymied.

Oliver
 

-----Original Message-----
From: Mark Miesfeld [mailto:[email protected]] 
Sent: 01 July 2011 15:56
To: Open Object Rexx Users
Subject: Re: [Oorexx-users] Binary Menu Bar (again)

On Fri, Jul 1, 2011 at 8:20 AM,  <[email protected]> wrote:

> Has the latest ooDialog release changed the Binary Menu Bar parameters?

Yes.  I think I had posted here notifying that, but maybe not.  But, looking
at things farther below, your problem is with symbolic IDs

There was a support request about this, and I also explained it there.
 Here is a direct link to that tracker item:

https://sourceforge.net/tracker/?func=detail&aid=3322913&group_id=119701&ati
d=684731

which is titled:  3322913  scriptmenybar in lastest oodialog 4.2 beta

reading that tracker item should help explain things.

In a way this goes back to the early discussion about methods of a dialog
object versus methods of a dialog control.

As you know, ooDialog allows the programmer to use symbolic IDs for
arguments that are a resource ID.  Internally ooDialog translates the
symbolic ID to the necessary numeric value.  It does this through the
constDir attribute of the dialog.

This works great, as long as *every object* is a dialog.  It falls apart as
soon as you start introducing objects that are not dialog objects, that use
resource IDs.

When I first added the Menu classes, I wanted to use symbolic resource IDs
in them.  Which was a problem, the translation mechanism was only in dialog
objects.

I worked around that by having one of the arguments to a new Menu object be
the source of the constDir.  The source constDir then got copied into the
menu object.  This was hokey and has its own set of problems.  What if the
programmer adds symbolic IDs to the original
constDir *after* the menu object was created?   Menu objects can be
attached to different dialog objects at different times in the life-cycle of
the program.  What then?

I then added in ResourceImage, Image, and ImageList objects.  All of which
also use resource IDs.  There, I just punted and said for these objects, all
resource IDs must be numeric, you can not use symbolic IDs.

Then, in May, I was working on some other new objects, which also use
resource IDs, and I thought, this is absurd, everything is *not* a dialog.
The mechanism to resolve a symbolic ID to its numeric value needs to be move
out of the dialog object.  Which I did.  (Actually, to preserve backwards
compatibility, the dialog object constDir and its usage remain unchanged and
a new global .constDir is added.)

Once I did that, I could remove the hokey code in the Menu classes related
to symbolic IDs.

The short of it, is that if you want to use symbolic IDs in menu objects you
have to use the global .constDir.

The UserMenuBar and ScriptMenuBar menu sample programs show how to do this.
In the BinaryMenuBar, it looks like I just used numeric resource IDs.  But,
between the other 2 samples and the tracker item, you should be able to see
what to do.

Let me know if you still can not get it to work and I will rewrite the
BinaryMenuBar example to use symbolic IDs.

--
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



------------------------------------------------------------------------------
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

Reply via email to