HMGforum.com

Hi Francesco.

oQtObject is now protected.
But sometimes I am using it directly, specially when what I want wasn´t possible with HMG4.
Being protected we loose a lot of possibilities and to me this is just this, a loose.
Anyway, I can unprotect it in the lib and use as I want.

These is an access method, qtObject.

So you should only search/replace in your source code from oQtObject to qtObject.

Please, if you feel that what is missing can be valuable to others please tell us so that we can add to hmg4...

concentra wrote:Hi Francesco.

oQtObject is now protected.
But sometimes I am using it directly, specially when what I want wasn´t possible with HMG4.
Being protected we loose a lot of possibilities and to me this is just this, a loose.
Anyway, I can unprotect it in the lib and use as I want.

Also lAccepted in Dialog was made protected.
This logical flag indicates if the dialog was accepted or rejected ( ok / cancel ) by the operator.
We need to access the var in order to decide what to do after the dialog is closed.
Are all vars in the controls made protected ?
If so, have I to use a method to access every vars ?

concentra wrote:If so, have I to use a method to access every vars ?

generically speaking, YES

This should have been imposed from day 1... well, from day 0. A class shoud be a black box, you should never have access to its data members directly.

I know this may sound strange, but I think it is mandatory.

If you REALLY need access to a internal variable WHOSE NAME/FUNCTION/SIDE_EFFECTS may CHANGE in the future (so you do at your own risk) you may subclass the prg class to add access methods.

mrduck wrote:These is an access method, qtObject.
So you should only search/replace in your source code from oQtObject to qtObject.

Ok.

Please, if you feel that what is missing can be valuable to others please tell us so that we can add to hmg4...

As i said before I am using HMG4 in production but I freezed an old HMG4 version in order to avoid problems.
Now I am upgrading my freeze version and some issues are arriving.

In this particular example, I have a Window with a toolbar, a virtualgrid and a statusbar and I want QT take care of positioning this 3 controls.
To do so, I created the window, inserted the 3 controls and settled the virtualgrid as the central widget.
No need to position nor size the virtualgrid.
The only way I found to do this in HMG4 was to add an extra widget to be the central one and put the virtualgrid inside it.
To avoid this extra unnecessary control I coded oWindow:oQtObject:setCentralWidget( oGrid:oQtObject ).

I am using HMG4 in production.

That is news to me.

mrduck wrote:

concentra wrote:If so, have I to use a method to access every vars ?

generically speaking, YES

This should have been imposed from day 1... well, from day 0. A class shoud be a black box, you should never have access to its data members directly.

I know this may sound strange, but I think it is mandatory.

Ok understood.

If you REALLY need access to a internal variable WHOSE NAME/FUNCTION/SIDE_EFFECTS may CHANGE in the future (so you do at your own risk) you may subclass the prg class to add access methods.

Almost all the time this will not be needed.
Possibly in a limit situation of a processing hungry function this overhead must be avoided, but as you said one can subclass.

rathinagiri wrote:That is news to me.

concentra wrote: The only way I found to do this in HMG4 was to add an extra widget to be the central one and put the virtualgrid inside it.

It's a Qt requirement, not hmg4.

Mauricio, please take some time to read about Layout management in Qt. It's a fantastic new world, with no coordinates nor widths, where Qt takes care of all resing.

To avoid this extra unnecessary control I coded oWindow:oQtObject:setCentralWidget( oGrid:oQtObject ).

In hmg4 there is layout and widget classes and there is the setCentralWidget method (centralwidgetof). So you should not need to use oQtObject.

mrduck wrote: Mauricio, please take some time to read about Layout management in Qt. It's a fantastic new world, with no coordinates nor widths, where Qt takes care of all resing.

I did, and that's why I coded to set the central widget.

In hmg4 there is layout and widget classes and there is the setCentralWidget method (centralwidgetof). So you should not need to use oQtObject.

As I said, to set the central widget in HMG4 an extra control must be added.
And in my opinion this should be implemented in basic or control in order to permit any control be the central widget without the need to add this extra layer.