HbQt QmainWindow QBarMenu

[l3whmg]

Hi guys please help me!
I want understand how HbQt create QBarMenu and how I can use it. Are three days on it and I have problems

I look at HMG4 and then I try to write code but it doesn't work
So, I compiled "harbour\contrib\hbqt\tests\demoqt.prg" and it work fine
I say to me: you have done mistakes

I copy and paste souce code from "demoqt.prg" into another source (you find it in attachement).
I compiled, run and... it doesn't work I don't see any menu

Is there some one can help me?

Cheers

[concentra]

Luigi, I had problem testing some samples and realized that the .EXE tested Ok in the binary distribution and doesn´t in the SVN one.
Seems to be related to QT dlls, paths and the qt.conf file but i didn´t look for the solution.

[mrduck]

Luigi, I had problem testing some samples and realized that the .EXE tested Ok in the binary distribution and doesn´t in the SVN one.
Seems to be related to QT dlls, paths and the qt.conf file but i didn´t look for the solution.

Today I and Luigi solved the problem. Now the hbQt objects are REAL harbour objects and when they go out of scope the Qt object is deleted. So the menu is created and then deleted..

[l3whmg]

Hi Mauricio, many thanks for you interest.
It's my problem because I'm trying to understand logic beyond QMenuBar, QMenu and QAction and how HbQt manage these. MrDuck open my eyes and now I'll do some experiences.
When you write "I had problem...", do you refer about this post or do you have other problems?

Cheers

ps sorry for this later.

[concentra]

Hi Luigi !

When you write "I had problem...", do you refer about this post or do you have other problems?

This post. The problem I had I didn´t try to solve because the same .EXE runs ok in other path.
[[]]

[l3whmg]

Hi Rathinagiri, I hope you can receive advice of this post replay

I've rewrite the MainMenu system (QTBarMenu) with and for my experimental gui. This is a simple screenshot

screenshot

ScreenShot001.jpg (26.96 KiB) Viewed 5471 times

And this is the look of the source code (OOP) in a program

Code: Select all

   WITH OBJECT oForm1 := HMGWINDOW():New( "form1" )

   WITH OBJECT L3WBMENU():New()
      :AddPopUp( "&File" )
      :AddItem( "item1.1", {|| MsgInfo( "I'm Happy item1.1") } )
      :AddSeparator()
         :AddPopUp( "&SubMenu" )
         :AddItem( "Subitem2.1", {|| MsgInfo( "I find Subitem2.1!") }, hb_DirBase()+"open.png" )
         :AddItem( "Subitem2.2", {|| MsgInfo( "I find Subitem2.2!") }, NIL, NIL, .F. )
         :AddSeparator()
         :AddItem( "Subitem2.3", {|| MsgInfo( "I find Subitem2.3!") } )
         :EndPopUp()
      :AddItem( "item1.2", {|| MsgInfo( "I'm Happy item1.2") } )
      :AddItem( "Close", {|| CloseForm() }, hb_DirBase()+"new.png" )
      :EndPopUp()
      :EndMenu()
   END WIDTH

   END WIDTH

   oForm1:Activate()

I used almost the same technique to link form and menu but oMainMenu is the only shared var

Code: Select all

   IF VALTYPE( ::oMainMenu ) <> "U"
      ::oQTObject:setMenuBar( ::oMainMenu:QTObject )
   ENDIF

As you can see there are some differences with current HMG4:
1) there are not varname before AddItem and AddPopUp. This because I have written the source code using internal referenced vars.
2) I used inheritance. I can write the previous code in this way (to "manage" menu)

Code: Select all

   WITH OBJECT oMenu1 := L3WBMENU():New()
      :AddPopUp( "&File" )
etc, etc.
      :EndMenu()
   END WIDTH

   MsgInfo( oMenu1:mnuvar_1:Title ) -->"mnuvar_" it's fixed 1 because is the first and show "&File"
   MsgInfo( oMenu1:mnuvar_3:Title ) --> 3 because is the third and show "&SubMenu"
   MsgInfo( oMenu1:mnuvar_3:menuvar_4:Caption ) --> 4 because is ... and show "Subitem2.1", preceded by :mnuvar_3

I wanna try to update HMG4 with this, but before I need your help to remember me:
about AddItem within hmg.ch I find this "NAME <oObj>" at the end. Regarding HMG3 compatibility: I don't remember if "NAME" can be assigned and used in a program to manage (?) menu item/popup OR this is for HMG4 ? We must keep "NAME..."?

As a result of this clarification, I will try to bring you the modified HMG4 source code before any commit because between HMG4 and my experiment there are some differences and I must find out problems.

Cheers

[Rathinagiri]

Hi Luigi,

I will go through your post thoroughly again and come with a reply soon.

Thanks man. It looks great.

[l3whmg]

Hi friends

as I anticipated, I wanted to rewrite the portion of source code about menu.

To test simply compile and run.
To avoid collisions with the current system, where necessary, I used the sign L3W (which will be removed if we use it).

The goals I set myself were:
A) get a syntax - and thus a structure - like this: varname1:Caption
B) avoid use of variables in the preprocessor
C) attach menu to its parent and to allow (if possible) inheritance of values

Defects
- after activation of the form, and thus the menu, you can not change its structure and content
- you can not assign names to the elements; names have the form HMGMNU_n
- all that you will find

Merits
- behavior is similar to other HMG objects, inheritance, etc..
For example: the creation of the QT object is determined by the function CreatePendingChildControls of the form (see C)

If this fix will have your approval, the changes - to HMG4 - will be:
1) remove menupopup and menuitem from Hmg4
2) replacement of mainmenu with classes and xxxMENU xxxMNUBAR
3) remove oDefaultMenuItem, aDefaultPopup, nPopupIndex var from window.prg
4) remove these lines from window.prg

Code: Select all

   IF ValType( ::oMainMenu ) != 'U'
      ::oQTObject:setMenuBar( ::oMainMenu:oQTObject )
   ENDIF

I hope you want to try what I have achieved. I await your opinions and criticism.

Cheers

p.s. I don't want to be tedious, but once again I would reiterate the need to review the source code of HMG4.
you will notice that in order to manage inheritance and use functions and variables, the class has been derived from both control.prg that window.prg: theoretically, it is not necessary.
Unfortunately, many functions are duplicated (FontName, FontSize, etc..) others lack (Font, FontBold, etc.).
Not always the child object can inherit from his father or it inherits too late.
For example: if I fix a FontName for the form all its children should use this FontName, unless I do not change for the single object.

[concentra]

Hi Luigi !

I think we are doing kind of the same thing!

p.s. I don't want to be tedious, but once again I would reiterate the need to review the source code of HMG4.
you will notice that in order to manage inheritance and use functions and variables, the class has been derived from both control.prg that window.prg: theoretically, it is not necessary.
Unfortunately, many functions are duplicated (FontName, FontSize, etc..) others lack (Font, FontBold, etc.).
Not always the child object can inherit from his father or it inherits too late.
For example: if I fix a FontName for the form all its children should use this FontName, unless I do not change for the single object.

I created a NEW() method for almost every control in HMG4, preserving the actual syntax and behavior.
Since I had compatibility problems with some controls, related to bad inheritance, I had to change the code in order to preserve the compatibility. This drove me to enhance inheritance and parent referencing.
This eliminated problems with inherited properties like Font().
The next step I planned was to eliminate duplicated functions...

B) avoid use of variables in the preprocessor

I was able to eliminate the preprocessor oCurrentTab, oPriorTab, oCurrentPage, oPriorPage controlling stuff, correcting the Tab/Tabpage parent/child relation.
And I think we can eliminate the oContainer too ( have to test all samples first )...

And with few exceptions, I didn´t change any control that inherited from WINDOW, so I didn´t changed menus because I didn´t have compatibility problems with them. So we can merge here !

But as I stated in a post here ( I am posting this after posted that, please see ), I need to know how do I include a lib by default in the building process.

[l3whmg]

Hi Mauricio, I look to your job and I think it's a good job.
When I write "rewrite code..." I don't think "change the behavior" but only "write more clean/simple".
For this reason, I think the first action is to have the same container for all the controls (form, label, etc.) Why? In this way, we can realize what has already been written or whether it should be adapted specifically for the object. In addition, if the definition of variables or methods are in one/two containers that can be taken easily.
In fact, even the Qt library holds a high regard about inheritance and relationship.
This is a simple example to explain my pov
I write two simple UDF named "FontInherit" and "FontSetup"; they are in the new method. The first sounds like this:

Code: Select all

IF VALTYPE( ::oFont ) == "U"
   ::oFont := ::oParent:oQtObject:Font()    <----take a look it can be ::oFont := ::oParent:oFont
ENDIF
IF VALTYPE( ::cFontName ) == "U"
  ::cFontName := ::oFont:Family()
ENDIF
etc....

The second is

Code: Select all

::oFont :setFamily( ::cFontName )
etc.
::oFont:setBold( ::lFontBold ) 
etc

In this way, the first inherit and create "default" font, the second one setup font for this object. These functions are in a big container and form, label, etc can use it. In Hmg4 The problem is: font is setup in the "activate" method. For this reason, all children have problems. I think, we must move "::oFont := QFont" from activate method to new method. The management of the font should not depend on the creation of the "object".

Other reasons indicate the need to think differently about the heart of HMG4. For example (about Harbour class) I can define "METHOD Width...." in "control.prg" and I can redefine "METHOD Width" in "window.prg". Wrong? I think no, because I can have a "standard METHOD Width" (and it works for most items) and I can have a different way for a specific object.

All these words to say: I think your job can be more simple after a hard job.

Cheers