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 » Sat Apr 16, 2011 10:59 am

Hi Rathinaigiri,
I'm in agreement with you. ;)
I do some test with my experimental gui and I think "::lCreated" or "Create" method it's a must for some reason 8-)

As I write to MrDuck, I am willing to make a draft on which reason in according with instructions that come from a briefing with all the people :!:

My pov to start is: create base classes (eg control and application), form class and label class: all in a very simple way, but to give us the idea of the target. Obviously, I can copy and past a lot of work from current HMG4 :D

Best regards
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 » Sat Apr 16, 2011 3:06 pm

Hi.
l3whmg wrote:I'm sorry but I don't understand your pov :!:
My pov was that it´s safer to do small changes preserving the compatibility than big ones that may brake current code that someone may be using. But now I think that it´s better to freeze the current trunk and make a fork.
l3whmg wrote:As MrDuck write, this change it's very important: all team must stop to write and owner must say yes. Ok?
Ok to me.
Anyone do not agree in start doing this ?
l3whmg wrote:I do some test with my experimental gui and I think "::lCreated" or "Create" method it's a must for some reason
Agree, in some situations this is needed.
l3whmg wrote:My pov to start is: create base classes (eg control and application), form class and label class: all in a very simple way, but to give us the idea of the target. Obviously, I can copy and past a lot of work from current HMG4
Luigi could you design a small chart with the hierarchy of the classes and post here, so everyone interested can agree ?
No need to be very detailed, just as simple as possible.
After that, we can make a fork in SVN and you put the skeleton base classes and we divide the classes sharing the job with the interested in it.
In the mean time I can revise the samples code because they are out of the coding formating rules.
[[]] Mauricio Ventura Faria

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

Post by mrduck » Sat Apr 16, 2011 6:18 pm

Ok, so we all agree: before starting to code each one with his own ideas, we will share them, think about them, talk about them, and then all together do a choice... so the result will be the result of everybody best ideas...


Luigi, take the hmg equivalent of QLabel and QLineEdit and list all the cumulative DATA/METHODS, and in which class they are defined, and start to rethink the different "layers": which are the common rules, which are the distinctive ones...

Please also remember a thing that I suppose was present in hmg-3 and not in 4 (can you confirm?): joining a "widget" with a harbour variable. so if I join variable mVar to a QLineEdit, if I access mVar I should read the value on the screen, and we I assign a value to mVar I should put that value. It souldn't necessarily done with a DATA SETGET, but I may call a function to set all values and to retrieve the values... it can be really usefull in WHEN/VALID handling

Two more things:

1)
we should start to settle on names... each "thing" should have a name... is it ok to call a slider, a spinner, a button, a tree, etc generally a "widget" ?

2)
PLEASE PLEASE spend some time on google to see the power of layouts ! to use Qt at the best we need to use layouts... and to have better forms with "automatic" menu, statusbar, docked windows, moveable and configurable toolbars we need to use QWidget inside QMainWindow...

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

Post by l3whmg » Sat Apr 16, 2011 9:45 pm

I've received the message ;) .
I'm working to collect informations.

Cheers
Luigi from Italy
www.L3W.it

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

Post by mrduck » Sat Apr 16, 2011 11:08 pm

l3whmg wrote:I've received the message ;) .
I'm working to collect informations.
you know you are a skype PM away if you need cooperation :-)

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

Post by l3whmg » Tue Apr 19, 2011 4:13 pm

Hi friends.
Here you can read my pov about HMG4 revision. Attached, you will also find an example of a revision of HMG4 (based on the image).

The image shows what I mean about the hierarchy.
g3879.png
scheme
g3879.png (7.86 KiB) Viewed 909 times
The basic classes are: SHARED and BASEOBJ. See below about PARENT.

The differences are not huge. I believe you will be able to grasp the structure.
The only addition that I propose are:
A) the identification of a class that controls start of QT applications (see "app.start"). In this way we can have a big super class. I named HmgWindows.
B) a class to manage relationship (see "PARENT"). Why this? Because hmg-application needs some basic values but not all values from "BASEOBJ" and for other reason.


1) The big difference is the New method for every object (like concentra job). Here you will find:
- the name of the object. It's mandatory to have one: with parameter or created
- the parent of the object. It's mandatory to have one: with parameter or retrieved with function (see 5 below)
- adding the HMG object to it's parent
- create the QT object (it's not the HMG create)
In this way we can have immediatly the inheritance: <HmgWindows:>form:control:control:....:value for HMG.
About Qt object we can minimize source code and other.

2) Each object must have the CREATE method (except a few specific cases). This is like a "QT object setup"; all METHOD test ::lCreated value

3) The other big difference are the source code for every method. Take a look and compare with HMG4.

4) Each object, which has children, should use the "CreatePendingChildControls. Theoretically, you could always use this function.

5) To manage parent level, I used a simple array. Form, Tab and other modify the contents of this public array (push-in and take-out)

6) Future: I think DATA must be always PROTECTET. For this reason everyone DATA must have its METHOD. Take a look to oQtObject and QTobject METHOD.

QT have a lot of ability and possibility. Many time the difference it's only the "command". I'm speaking - for example - about
icon. Icon is a character var, it contains the reference to an image. But I can use this for window icon or about image in a button or in a label.
With HMG we can minimize use of DATA. Using a var (and its contents) depend on the object under construction:
eg. "::oQtObject:setWindowIcon( ::cIcon )", "::oQTObject:SetIcon( ::cIcon )", etc.
Please take a look to cIcon within window and button (see hmg-include.ch too).

Well, to compile and run:
1) To compile lib and samples you have two possibility:
  • 1.a) copy Harbour distribution package at the same level of svn folder
  • 1.b) change path within:
    - this row "SET HRBPATH=..\Harbour\bin" within buildlib.bat
    - this row "SET HRBPATH=..\..\..\Harbour\bin" within buildapp.bat
  • 1.c) run buildlib.bat to create lib; it creates hb_error.log
  • 1.d) run build.bat (within samples\subfolder) to create sample; it creates hb_error.log
2) Before run samples, you must copy QTcore4.dll, QTgui4.dll, QTnetwork4.dll. There are two types of sample: HMGx style OOP style.

I am at your disposal for any further information.

Cheers
Attachments
Hmg4Revised.zip
sources
(2.36 MiB) Downloaded 68 times
Luigi from Italy
www.L3W.it

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

Post by mrduck » Wed Apr 27, 2011 9:38 pm

Sorry Luigi for my late (and probably incomplete) answer.

I browsed your code and I liked it, it's exactly what we were talking about.

There are some points I don't understand, like the use of lCreated... why is it checked ? isn't the Qt object created at "new" ?

Reading demos source code I see that there is a HmgWindows variable that is "program wide"... in btn_demo1a you define form1 as plublic but not in btn_demo1....

I was also thinking about ONCLICK btn1_Click()
STATIC FUNCTION btn1_Click()
HmgWindows:form1:Release()
RETURN NIL

You need to use full "hierarchy path" HmgWIndows:form1:release() since you don't have any reference from the calling function. This "path" makes the code less reusable.
It would be good if we could know in the btn1_click() function which is the object that created the event. It can be achieved in two ways: passing the object as first parameter, asking HMG (I think hmg3 uses this method)

So the code would be:
STATIC FUNCTION btn1_Click()
Hmg_getObject():getForm():Release()
RETURN NIL

// getForm should return the form the widget is in, not just the parent

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

Post by l3whmg » Thu Apr 28, 2011 8:10 am

Hi MrDuck and to everyone.
I'm sorry for my silence in these days; unfortunately I was sick: fever and sore throat. I got up out of bed, only two days.
mrduck wrote:There are some points I don't understand, like the use of lCreated... why is it checked ? isn't the Qt object created at "new" ?
Of course, QtObject it's created in the new method, but in this way I can apply "every" property in a right way and in a good order ELSE could happen to apply a property - before or after - without needing a reasonable effect. For example: if I activated the property "AutoSize" of a label, I must set the text and the font size before I can use any QT commands. With lCreated I can control the moment: the first time (lCreated is false) I manage properties inside Create method in a right order THEN (lCreated is true) I can manage properties in every moment and in every way (with some risk!!).
mrduck wrote:Reading demos source code I see that there is a HmgWindows variable that is "program wide"... in btn_demo1a you define form1 as plublic but not in btn_demo1....
I think about your idea to have a BIG father: it can be sound like "windows...". Perhaps, it's not the best way, but in this way I can have only one public object and I don't need to declare public every form (I remember the Hmg3 command DECLARE WINDOW at the beginning of prg source to take property or manage a control about form defined in other source).
mrduck wrote:You need to use full "hierarchy path" HmgWIndows:form1:release() since you don't have any reference from the calling function. This "path" makes the code less reusable.
It would be good if we could know in the btn1_click() function which is the object that created the event. It can be achieved in two ways: passing the object as first parameter, asking HMG (I think hmg3 uses this method)

So the code would be:
STATIC FUNCTION btn1_Click()
Hmg_getObject():getForm():Release()
RETURN NIL
You are right: I don't think about this. In this moment, I can't figure out "how to": Hmg_getObject():getForm(). I'll try.

Cheers

p.s. see you soon on skype
Luigi from Italy
www.L3W.it

Post Reply