I want to offer a different solution for menu management.
Attached, you will find a compressed file with everything you need to check my proposal.
CAUTION: what you find is a proposal, which alter the contents of your HMG4 distribution.
Therefore, you must preserve a valid copy of the HMG4 library (before copying this content) and
when finished you must restore the originals.
THIS IS THE CONTENT:
hmg.hbp : added lqt-menu.prg and removed: source/mainmenu.prg, source/menupopup.prg, source/menuitem.prg
source/lqt-menu.prg : the new menu management system
source/window.prg : added DATA oMainMenu and SetUpMenu() method
include/hmg.ch : to handle XBase command styel
samples/newmenu : folder with demo (note: after evaluation you must remove it)
BRIEF EXPLANATION:
The code is based on creating nested objects inside the class.
In this phase, are created only HMG4 objects. The real QT menu is activated with the CREATE() method.
This method is called by the function "CREATEPENDINGCHILDCONTROLS" within the class WINDOW. In this way I preserve the HMG4 logic.
Unlike the previous version, I add that:
- there are only two classes, but the real used it's only one
- external variables are not necessary, reducing the load of code into the file "HMG.CH"
2011-07-09 THIS lines below ARE WRONG
VERY IMPORTANT REMARK:
I was able to maintain compatibility with HMG3, about this syntax: MainForm.ItemMenu.value, but I believe
that this compatibility is to be DEPRECATED because it's completely out of HMG4 logic and it's very dangerous!
Moreover, as the current version, this "compatibility" creates a serious problem: there are two identical objects, but positioned at different level.
Within the HMG4 library, this is a hypothetical creation of an item: Mainform:MainMenu:MenuPopUp:MenuItem.
Wanting to maintain compatibility with HMG3, is added an object in this way: Mainform:MainMenu:MenuItem.
They have the same name, the same properties, but may contain different settings: depending on the access method chosen by the programmer.
In example:
- if I use this ===> Mainform:MainMenu:MenuPopUp:MenuItem:Enabled := .F.
I must repeat ==> Mainform:MainMenu:MenuItem:Enabled := .F.
ELSE
I can have the first one disabled and the second one enabled.
2011-07-09 end correction
You can follow this compatibility, looking for this "aHmg3Comp" var name within the class.
If we remove this var and related use, we remove the HMG3 compatibility.
DEMO SOURCES:
demo_1.prg: demonstrates the use of the class, OOP syntax, but without assigning names to objects
demo_2.prg: demonstrates the use of the class, with XBase syntax, but without assigning names to objects
demo_3.prg: demonstrates the use of the class, OOP syntax, with assigning names to objects
demo_4.prg: demonstrates the use of the class, with XBase syntax, with assigning names to objects
I introduced some new features:
- You can define the font, which is inherited by every object that make up the menu
- Include icons
- Assign a name to all objects that make up the menu
At this time, I preferred to keep clear the difference from the HMG4, using different names.
Obviously, these will be aligned if it sees fit to apply this solution.
The only thing that I intend to keep different than HMG4, is the internal name of the object (generated automatically).
HMG4 use this solution: "'_HMG_OBJECT_' + hb_nToS(...." you can find in control.prg
I want use this: "'_HMG_MENU_' + hb_nToS(....".
In this way we can identify menu object and having: a different prefix name and a number sequence dedicated (see nMnuObjCounter)
Well, that's all folk.
I will wait your opinions.
2011-07-09 I have update zip file