Menu
▾
▴
[Oorexx-bugs] [ oorexx-Support Requests-3322913 ] scriptmenybar in lastest oodialog 4.2 beta
|
From: SourceForge.net <no...@so...> - 2011-06-21 18:15:01
|
Support Requests item #3322913, was opened at 2011-06-20 10:16 Message generated for change (Comment added) made by hexit34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684731&aid=3322913&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: ooDialog Group: Windows Status: Open Priority: 5 Private: No Submitted By: hakan (hexit34) Assigned to: Mark Miesfeld (miesfeld) Summary: scriptmenybar in lastest oodialog 4.2 beta Initial Comment: It seems that I can't figure out how to use .scriptmenubar in the lastest beta build of OODIALOG 4.2. Earlier I used (which worked with a build from 6898 made april 2 ) ::method InitDialog menu_dlg = .scriptmenubar~new("MydialogName.rc",IDR_MENU1,"MydialogName.h") menu_dlg~attachto(self) but this doesn't work in latest build As there is no sample code for scriptmenubar, I looked at the usermenubar example, mentioned there is .application~useGlobalConstDir("O", "UserMenuBar.h") So I tried .application~useGlobalConstDir("O", "MydialogName.h") ..... menu_dlg = .scriptmenubar~new("MydialogName.rc",IDR_MENU1) menu_dlg~attachto(self) but no success on that. Please also add an sample of a scriptmenubar in OOdialog samples directory Thanks ---------------------------------------------------------------------- >Comment By: hakan (hexit34) Date: 2011-06-21 20:14 Message: Well, just thinking that rexx itself i caseinsensitive, uninitialized variables are initilized to it's uppercase name and a variable is caseless when used in a program (VARname & vArNaMe is the same variable). I prefer to think of a OOdialog symbols as an uppercased uninitialized rexx variable and when put in constdir will be uppercased and get a numeric value or other value that can be a lowercase word. Otherwise one must start to quote the symbolname in the oodialog rexx program (ie self~DisableMenuItem("IDM_ProfileNew") instead of self~DisableMenuItem(IDM_ProfileNew) the later will be uppercase by rexx I assume) The above is my preference. Maybe others can give their opinion, as I am more a mainframe rexx person than OOrexx person, despite that I try to learn OOrexx and OODialog. Regarding the menuex in the .rc file I have not a clue how It got there in the first place. But after removing the menuseparator items in the .rc file the .scripmenubar works in the latest OOdialog again.(i also had to uppercase the symbolnames in the .h and .rc file in the program I didn't need to change the symbolnames to uppercase, rexx did that ) Menus with separator items worked in my own build of SVN 6898 for win7 64bit and 32 bit xp ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-06-21 17:46 Message: "One problem seems to be when using mixed case in resource .h file, these are stored asis in .constdir " Yes that is one of the optimizations in the global constDir. There is actually a fair amount of overhead in doing symbol lookup case insensitve. If you think case insensitve symbol look up is important, I can take out the optimizations. The thing is, I would always use symbolic resource IDs, and I would like the look up process to be optimized. To me, a constant symbol is constant. The symbol, idm_FILE is always idm_FILE and not equal to the constant symbol IDM_FILE. Let me know if you think I should change this lookup to be case insensitve. The problem in the menu, is that ResEdit is producing a menu template using the MENUEX format. In this case specifically, the separtator statement is not being recognized as a separator. ooDialog only has code for parsing MENU format menus. The menu classes actually use MENUEX menu templates, but I never wrote a parser for MENUEX, because I can not get my ResEdit to produce MENUEX menus. And, I don't know of any other resource editor that does. So, I don't have anything to test the parser with. It seems to me that this .rc file would have failed with the previous beta of ooDialog 4.2.0. I don't recall any changes I made that would cause it to fail now, if it was working before. I don't see a quick solution here. Writing a MENUEX parser is the thing to do, but it will take me a bit to do it. ---------------------------------------------------------------------- Comment By: hakan (hexit34) Date: 2011-06-21 17:12 Message: One problem seems to be when using mixed case in resource .h file, these are stored asis in .constdir But still have problem +++ "WindowsNT METHOD C:\MyRexx\dialog\spvreset.rex" 69 *-* menuBar = .ScriptMenuBar~new(self~dialogName||".rc",IDR_MENU1, , , .false, self) Error 88 running C:\MyRexx\dialog\spvreset.rex line 69: Invalid argument Error 88.916: Argument 1 must be one of a positive numeric ID or a valid symbolic ID; found "0" In unInit() of MenuBar class ---------------------------------------------------------------------- Comment By: hakan (hexit34) Date: 2011-06-21 12:39 Message: Thanks your sample works perfect. But I can't get my own template dialog to work. Attached a template dialog I am using for my own oodialog programs. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2011-06-21 00:25 Message: You were on the right track with the useGlobalConstDir, this should have worked: So I tried .application~useGlobalConstDir("O", "MydialogName.h") ..... menu_dlg = .scriptmenubar~new("MydialogName.rc",IDR_MENU1) menu_dlg~attachto(self) I started an example program for a ScriptMenuBar and it will be added to the samples. I'm attaching it so you can see it works. I'd need to see more of you program to tell why it didn't work for you. A word on the global constDir. The original developers used the constDir attribute of a dialog to supply a way of using symbolic IDs in ooDialog programs. It worked okay as long as every object is a dialog. It starts to fall apart as other objects are added to the system. With menus, I cobbled together a solution where one of the arguments to new() was the "source" of the constDir for the menu. When I added the .ResourceImage and .Image classes, I just punted and said you could use symbolic IDs for those. Then I went to add another new class, and wanted to be able to use symbolic IDs. Since the menu classes have never existed in a formal release, I decided to just fix this and refactor the menu classes. Now each ooDialog program will contain a .directory object in the local environment, called constDir, accessed by .constDir. Each program will also contain a singleton instance of the ApplicationClass in the local environment accessed by .application. The ApplicationClass is used for application wide settings and defaults. The only use for it now, is to set how the global .constDir is used. By default, for backwards compatibility it is not used. You can set its use to 'Only' 'First' 'Last' or 'Never' With only, the .constDir is the only constDir used. The constDir attribute is ignored. With first, when a symbolic ID needs to be used, the global constDir is searched first, then the constDir attribute. With last, the reverse. And with never, the global constDir is ignored. If you use symbolic IDs in your programs, you should switch over to using the application~useGlobalConstDir("O", "MydialogName.h") form. This form optimizes the lookup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684731&aid=3322913&group_id=119701 |