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&atid=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
