Protected oQtObject
Moderator: Rathinagiri
Protected oQtObject
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.
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.
[[]] Mauricio Ventura Faria
Re: Protected oQtObject
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...
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.
Re: Protected oQtObject
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 ?
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 ?
[[]] Mauricio Ventura Faria
Re: Protected oQtObject
generically speaking, YESconcentra wrote:If so, have I to use a method to access every vars ?
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.
Re: Protected oQtObject
Ok.mrduck wrote:These is an access method, qtObject.
So you should only search/replace in your source code from oQtObject to qtObject.
As i said before I am using HMG4 in production but I freezed an old HMG4 version in order to avoid problems.Please, if you feel that what is missing can be valuable to others please tell us so that we can add to hmg4...
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 ).
[[]] Mauricio Ventura Faria
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: Protected oQtObject
That is news to me.I am using HMG4 in production.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.
South or North HMG is worth.
...the possibilities are endless.
Re: Protected oQtObject
Ok understood.mrduck wrote:generically speaking, YESconcentra wrote:If so, have I to use a method to access every vars ?
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.
Almost all the time this will not be needed.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.
Possibly in a limit situation of a processing hungry function this overhead must be avoided, but as you said one can subclass.
[[]] Mauricio Ventura Faria
Re: Protected oQtObject
It's a Qt requirement, not hmg4.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.
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.
In hmg4 there is layout and widget classes and there is the setCentralWidget method (centralwidgetof). So you should not need to use oQtObject.To avoid this extra unnecessary control I coded oWindow:oQtObject:setCentralWidget( oGrid:oQtObject ).
Re: Protected oQtObject
I did, and that's why I coded to set the central widget.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.
As I said, to set the central widget in HMG4 an extra control must be added.In hmg4 there is layout and widget classes and there is the setCentralWidget method (centralwidgetof). So you should not need to use oQtObject.
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.
[[]] Mauricio Ventura Faria