HbQt QmainWindow QBarMenu

Moderator: Rathinagiri

User avatar
l3whmg
Posts: 694
Joined: Mon Feb 23, 2009 8:46 pm
Location: Italy
Contact:

Re: HbQt QmainWindow QBarMenu

Post by l3whmg » Fri Apr 15, 2011 8:33 am

Hi this can be another example to show what I mean
this come from window.prg

Code: Select all

METHOD Row( nValue ) CLASS WINDOW
   LOCAL nCol

   IF ::lCreated
      IF Pcount() == 0
         RETURN ::oQTObject:y()
      ELSEIF Pcount() == 1
         nCol := ::oQTObject:x()
         ::oQTObject:move( nCol,nValue )
      ENDIF
   ELSE
      IF Pcount() == 0
         RETURN ::nRow
      ELSEIF Pcount() == 1
         ::nRow := nValue
      ENDIF
   ENDIF

   RETURN NIL
But i think can be this

Code: Select all

METHOD HMGBASEOBJ:Col( nArg1 )

   IF PCOUNT() == 0
      RETURN ::nCol
   ELSEIF VALTYPE( nArg1 ) == "N"
      ::nCol := nArg1
      IF ::lCreated == .T.
         ::nRow := IF( VALTYPE( ::nRow) == "N", ::nRow, ::oQTObject:y() )
         ::Move()
      ENDIF
   ENDIF

RETURN NIL
etc, etc...
METHOD HMGBASEOBJ:Row( nArg1 )

   IF PCOUNT() == 0
      RETURN ::nRow
   ELSEIF VALTYPE( nArg1 ) == "N"
      ::nRow := nArg1
      IF ::lCreated == .T.
         ::nCol := IF( VALTYPE( ::nCol) == "N", ::nCol, ::oQTObject:x() )
         ::Move()
      ENDIF
   ENDIF

RETURN NIL
etc, etc.
METHOD HMGBASEOBJ:Move()

    IF ::lCreated == .T.
         ::oQTObject:move( ::nCol, ::nRow )
   ENDIF

RETURN NIL
Luigi from Italy
www.L3W.it

User avatar
concentra
Posts: 256
Joined: Fri Nov 26, 2010 11:31 am
Location: Piracicaba - Brasil

Post by concentra » Fri Apr 15, 2011 1:50 pm

Hi Luigi.
l3whmg wrote: 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".
I did it.
l3whmg wrote:

Code: Select all

IF VALTYPE( ::oFont ) == "U"
   ::oFont := ::oParent:oQtObject:Font()    <----take a look it can be ::oFont := ::oParent:oFont
ENDIF
I took a different approuch: when a control object is created, it inherits the font from its parent and I took the font from the object itself. But both code results in the same font object.

Code: Select all

::oQtObject := anyQtObject( ::oParent:oQtObject )  <--- The created QT object inherits the font from its parent. 
::oFont := ::oQtObject:Font()    <---- just extract the inherited font
[[]] Mauricio Ventura Faria

User avatar
concentra
Posts: 256
Joined: Fri Nov 26, 2010 11:31 am
Location: Piracicaba - Brasil

Post by concentra » Fri Apr 15, 2011 2:01 pm

Hi Luigi.
l3whmg wrote:Hi this can be another example to show what I mean
Lets see if I got it.
There are a bunch of ROW() methods ( ROW is only an example, there are many others ) spread on the code, almost one for each control.
Your idea is to write a generic ROW() method in a "upper" class and eliminate all the redundant ROW() methods in the inherited classes.
And if a specific control needs a different code we just code it inside this control class.
Is it ?
If so, I totaly agree with you !
[[]] Mauricio Ventura Faria

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Fri Apr 15, 2011 3:09 pm

concentra wrote:Hi Luigi.
l3whmg wrote:Hi this can be another example to show what I mean
Lets see if I got it.
There are a bunch of ROW() methods ( ROW is only an example, there are many others ) spread on the code, almost one for each control.
Your idea is to write a generic ROW() method in a "upper" class and eliminate all the redundant ROW() methods in the inherited classes.
And if a specific control needs a different code we just code it inside this control class.
Is it ?
If so, I totaly agree with you !
Yes, this is the main idea... more precisely we should create different " building blocks"... please look at qt documentation and the class chain:
QLabel -> QFrame -> QWidget -> QObject & QPaintDevice
At each "level" (from right to left) you have specialized functions.
setText is in QLabel, because it has no meaning in QWidget, it is a QLabel specific...
All the tooltip stuff, dimensions, visibility, flags, event are in QWidget because they are common to all widgets.

In HMG we have control.prg, probably some methods may be moved from upper classes to control.prg AND some methods only used is some widgets should be moved to the widget class (or a medium-layer class created).

Then we may play with inheritance to overload methods and we can always call parent method if we just wanto to specialize it a bit...


It's not easy, but should be done... I proposed months ago but I don't have the time right now. In the main thread for example, look at my post of about one month ago when I proposed to Rathinagiri to review the code of the THREE different browse/grid we have now, where 90% of the code is duplicated...

User avatar
Rathinagiri
Posts: 5250
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 167 times
Been thanked: 165 times
Contact:

Post by Rathinagiri » Fri Apr 15, 2011 3:31 pm

I proposed to Rathinagiri to review the code of the THREE different browse/grid we have now, where 90% of the code is duplicated...
Yes. That's right. I am just uniting these three browse/grid/virtualgrid classes.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

User avatar
l3whmg
Posts: 694
Joined: Mon Feb 23, 2009 8:46 pm
Location: Italy
Contact:

Post by l3whmg » Fri Apr 15, 2011 3:58 pm

Hi, what I mean is what MrDuck write ;)
For this reason I send to this forum my (real) gui experiment: to show the benefits of this action! But, I write, we must stop development for a while and take time to rewrite the core.
As I show with my gui (I'm sorry, I know it's not the best, it's a beast :lol: ) we can have two (or more I don't know) great container: the first is for shared value (can be application.prg) and one for generalized data and method ( can be control.prg ). All the controls class (form, label, button, etc) are derived from these two class
eg:

Code: Select all

CLASS window FROM application, control
CLASS button FROM application, control
CLASS label FROM application, control
Within CLASS control we can have (for example)

Code: Select all

CLASS control
DATA nRow
....
METHOD Row             SETGET
...
METHOD Row ( nArg1 )
IF PCOUNT() == 0
   RETURN ::nRow
ELSEIFVALTYPE( nArg1 ) == "N"
  ::nRow := nArg1
  IF ::lCreated == .T.
....
     ::oQtObject:move( ::nCol, ::nRow )
 ENDIF
ENDIF
RETURN NIL
and all the objects (form, label, button, etc) can use this data and method.
when we have a specialized value or method we can add or rewrite (within object class) data or method.

This approach don't change the behavior or compatibility: it's the same!
At the same time (+- like today) we must think to have inheritance and parent using the create method for all the objects; in this way we can have formname:control:subcontrol:....value.

Please: take a look to my code. As you can see programs are like HMGx style but the library source code it's little different from HMG4 but give the same option.

Cheers
Luigi from Italy
www.L3W.it

User avatar
concentra
Posts: 256
Joined: Fri Nov 26, 2010 11:31 am
Location: Piracicaba - Brasil

Post by concentra » Fri Apr 15, 2011 5:44 pm

mrduck wrote:Yes, this is the main idea... more precisely we should create different " building blocks"... please look at qt documentation and the class chain:
QLabel -> QFrame -> QWidget -> QObject & QPaintDevice
At each "level" (from right to left) you have specialized functions.
setText is in QLabel, because it has no meaning in QWidget, it is a QLabel specific...
All the tooltip stuff, dimensions, visibility, flags, event are in QWidget because they are common to all widgets.
Yes, inheritance.
mrduck wrote:In HMG we have control.prg, probably some methods may be moved from upper classes to control.prg AND some methods only used is some widgets should be moved to the widget class (or a medium-layer class created).
Ok. I will start doing this.
l3whmg wrote:

Code: Select all

CLASS window FROM application, control
CLASS button FROM application, control
CLASS label FROM application, control
Luigi, I think we can take the current approach, with WINDOW and CONTROL inheriting from APPLICATION, clean the redundant code and pass to a different structure later, with a smaller code.
l3whmg wrote:in this way we can have formname:control:subcontrol:....value.
In the current SVN code we can do this ( not all the time, must be enhanced... ).
See the following statement in the code: oWindow.oTabLevel1.oPageTwo.oTabLevel2.oPageAlfa.oButtonPageAlpha.Caption

Code: Select all

#include "hmg.ch"

FUNCTION Main

hbqt_errorsys()

   DEFINE WINDOW oWindow
      Row 10
      Col 10
      Width 400
      Height 400
      Title 'Nice OOP Demo!!!'
      Type WND_MAIN
      OnInit oWindow:Center()

      DEFINE TAB oTabLevel1 ROW 10 COL 10 WIDTH 300 HEIGHT 300

         DEFINE PAGE 'One' NAME oPageOne

             @ 40,40 Button oButtonPageOne   ;
             CAPTION 'Page one Button'       ;
             ON CLICK MsgInfo( oWindow.oTabLevel1.oPageOne.oButtonPageOne.Caption )

         END PAGE

         DEFINE PAGE 'Two' NAME oPageTwo

            DEFINE TAB oTabLevel2 ROW 120 COL 20 WIDTH 180 HEIGHT 100

               DEFINE PAGE 'Alpha' NAME oPageAlfa

                  @ 15,15 Button oButtonPageAlpha   ;
                  Caption 'Page Alpha'              ;
                  Action MsgInfo( oWindow.oTabLevel1.oPageTwo.oTabLevel2.oPageAlfa.oButtonPageAlpha.Caption )

               END PAGE

               DEFINE PAGE 'Beta' NAME oPageBeta

                  @ 30,30 Button oButtonPageBeta   ;
                  Caption 'Page Beta'   ;
                  Action MsgInfo( oWindow.oTabLevel1.oPageTwo.oTabLevel2.oPageBeta.oButtonPageBeta.Caption )

               END PAGE

            END TAB

         END PAGE

      END TAB

   END WINDOW

   ACTIVATE WINDOW oWindow

   RETURN
[[]] Mauricio Ventura Faria

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Fri Apr 15, 2011 7:44 pm

concentra wrote:Ok. I will start doing this.
Thanks, but first I ask Luigi and Mauricio to talk about the things to do, since Luigi already did part of the work.... and since it is a "big" change I think that before changing all the files we should talk a bit before... Rathinagiri, for example, is working on merging browse/grids, and while he completes the job you can you give us an idea on what you are thinking to do, do you ? Just to have a shaerd acknowledgement

User avatar
l3whmg
Posts: 694
Joined: Mon Feb 23, 2009 8:46 pm
Location: Italy
Contact:

Post by l3whmg » Fri Apr 15, 2011 7:52 pm

Hi Mauricio,
About example ok.
concentra wrote:Luigi, I think we can take the current approach, with WINDOW and CONTROL inheriting from APPLICATION, clean the redundant code and pass to a different structure later, with a smaller code.
I'm sorry but I don't understand your pov :!:
WINDOW must be inherit from APPLICATION and CONTROL
BUTTON must be inherit from APPLICATION and CONTROL
LABEL must be inherit from APPLICATION and CONTROL
etc.
Could you please explain your way?

As MrDuck write, this change it's very important: all team must stop to write and owner must say yes. Ok?

Cheers
Luigi from Italy
www.L3W.it

User avatar
Rathinagiri
Posts: 5250
Joined: Tue Jul 29, 2008 6:30 pm
DBs Used: MariaDB, SQLite, SQLCipher and MySQL
Location: Sivakasi, India
Has thanked: 167 times
Been thanked: 165 times
Contact:

Post by Rathinagiri » Sat Apr 16, 2011 3:21 am

mrduck wrote:
concentra wrote:Ok. I will start doing this.
Thanks, but first I ask Luigi and Mauricio to talk about the things to do, since Luigi already did part of the work.... and since it is a "big" change I think that before changing all the files we should talk a bit before... Rathinagiri, for example, is working on merging browse/grids, and while he completes the job you can you give us an idea on what you are thinking to do, do you ? Just to have a shaerd acknowledgement
Hi,

Since the project is in initial stage, we have to try the options available for us and yes we really want an optimized and simplified framework. As Francesco, Mauricio and Luigi would agree, no duplication of code is required. We have to clean the stuff and make it a nice hierarchical structure for better understanding and future development.

If we can do away with ::lCreated and use the control name to hold the QTObject, yes, it is fine. In this regard, Luigi and Mauricio, are you ready to do this? We shall stop committing until you change the code completely to the new method.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

Post Reply