Hmg4 stylesheet
Moderator: Rathinagiri
Re: Hmg4 stylesheet
Hi.
I know that this can be a little off-topic in this post but...
I found in the Net a magnificent tutorial about Harbour and QT:
http://www.gruppoeratostene.com/harbour/ht.htm
And I will do some experimentation in using QT directly...
I know that this can be a little off-topic in this post but...
I found in the Net a magnificent tutorial about Harbour and QT:
http://www.gruppoeratostene.com/harbour/ht.htm
And I will do some experimentation in using QT directly...
[[]] Mauricio Ventura Faria
Re: Hmg4 stylesheet
Hi Mauricio,
I study your idea and about this
and of course, about control. My problem is: when i must stop the ricursive parent? When I create a new form? A form can (I think probably yes) have a subform?
Another question: in HMG4/HMG3 we can use this syntax "formname:controlname:Value". First: we must preserve the syntax with "name" and second, "formname" is (normally) local with my version (look at "windows:") we have this public syntax "windows:formname:control:value" (thanks to MrDuck to introduce me).
I hope my opinion is clear...sorry for English
Cheers
I study your idea and about this
In my vision the first parent is the desktop object created by QT. In my HMG this can be ricursive and for this reason I think we can have:The major difficulty I found is that, the way the lib is written, when a NEW() is called to create a control the parent isn´t known, it will be known only when the CREATE() method is called in the container window.
In QT controls, the first parameter is almost always the parent object.
In HMG4 the NEW() method should be called passing the parent as the first parameter NEW( parent ), just as in QT.
But I don´t know if there is a direct way to reference the upper parent in a nested WITH / END WITH structure.
Anyone ?
If not, a control heap needs to be used, probably as a public var. If I could understand the code in window.prg, this is the way the relation between parent / child is managed, and this will ned to be moved from the CREATE() to the NEW() methods.
Code: Select all
QtDesktop
|-->Form1
|-->Form2
|-->Form3
Another question: in HMG4/HMG3 we can use this syntax "formname:controlname:Value". First: we must preserve the syntax with "name" and second, "formname" is (normally) local with my version (look at "windows:") we have this public syntax "windows:formname:control:value" (thanks to MrDuck to introduce me).
I hope my opinion is clear...sorry for English
Cheers
Luigi from Italy
www.L3W.it
www.L3W.it
Re: Hmg4 stylesheet
Hi Concentra,
I understand what you want to do and I may agree with you. When I arrived in this project I could not explain a lot of the choices done in the code, and you may find my posts that are a bit "heavy" on this, proposing drastic changes.
They replied that the main goal of this project is to keep HMG3 compatibility. I think that this is a pity, since it is like forcing Qt to do less things and/or in a very schematic way. But this is their project and I adapted myself trying to adhere to their rules.
There are at least 2 ways to do the job: direct inheriting like you propose, or "decorating" like it is now. They have plus and minus.
For the status of the project as it is now, I sponsor the decorating way. It will give us a specific HMG API interface that we are forced to use. I think this will help in the long run. HMG has a defined BUTTON, defined in the meaning it has several properties. That is all HMG users need to know. How it is translated into Qt doesn't matter to them. It should be hidden. For the brave programmers there is always the opportunity to retrieve the Qt object or inherit from BUTTON... how many brave programmers you see here ?
The inheriting way gives the programmer apparently more power - power that you have anyway. Will give you better code structure ? I don't know, please provide more infos. I think about methods with the same names in hmg and qt but that do thing in a slightly different way that must be overloaded. Yes, you may remove some code... but ...
.. there are a lot of "problems" that - I think - are more important to be solved. There are too many public variables, methods should be moved into correct class (Luigi proposal), a lot of widgets are not complete, inconsistent, with not optimized code. The "get system" has some problems due to how QLineEdit behave. Someone created code for simulating a PICTURE but it is not complete and fields with and without PICTURE behave in a very different way. The get system should be widened to store return values, handle VALID and WHEN conditions according to GUI rules.
I started some of these changes in a private repository (call it a fork) and like I said earlier I will commit later, because I can't finish the changes without extensive testing.
Probably I don't understand correctly the reason of your proposal. Please expand on your ideas.
Francesco
I understand what you want to do and I may agree with you. When I arrived in this project I could not explain a lot of the choices done in the code, and you may find my posts that are a bit "heavy" on this, proposing drastic changes.
They replied that the main goal of this project is to keep HMG3 compatibility. I think that this is a pity, since it is like forcing Qt to do less things and/or in a very schematic way. But this is their project and I adapted myself trying to adhere to their rules.
There are at least 2 ways to do the job: direct inheriting like you propose, or "decorating" like it is now. They have plus and minus.
For the status of the project as it is now, I sponsor the decorating way. It will give us a specific HMG API interface that we are forced to use. I think this will help in the long run. HMG has a defined BUTTON, defined in the meaning it has several properties. That is all HMG users need to know. How it is translated into Qt doesn't matter to them. It should be hidden. For the brave programmers there is always the opportunity to retrieve the Qt object or inherit from BUTTON... how many brave programmers you see here ?
The inheriting way gives the programmer apparently more power - power that you have anyway. Will give you better code structure ? I don't know, please provide more infos. I think about methods with the same names in hmg and qt but that do thing in a slightly different way that must be overloaded. Yes, you may remove some code... but ...
.. there are a lot of "problems" that - I think - are more important to be solved. There are too many public variables, methods should be moved into correct class (Luigi proposal), a lot of widgets are not complete, inconsistent, with not optimized code. The "get system" has some problems due to how QLineEdit behave. Someone created code for simulating a PICTURE but it is not complete and fields with and without PICTURE behave in a very different way. The get system should be widened to store return values, handle VALID and WHEN conditions according to GUI rules.
I started some of these changes in a private repository (call it a fork) and like I said earlier I will commit later, because I can't finish the changes without extensive testing.
Probably I don't understand correctly the reason of your proposal. Please expand on your ideas.
Francesco
Re: Hmg4 stylesheet
Yes, it is.concentra wrote:HiI will assume that this is the syntax preprocessed with the hmg.ch and converted to the "with object" statements .mrduck wrote: In the process you have to keep compatibility with hmg-3 syntax, expecially it's "command like" syntax (1 of the 3 syntaxes you may use to write hmg-4 programs)
The major difficulty I found is that, the way the lib is written, when a NEW() is called to create a control the parent isn´t known, it will be known only when the CREATE() method is called in the container window.mrduck wrote: Ok, since you are already thinking about this change, I ask you to please write a message explaining the changes you have in mind and how they adapt to hmg-4 and qt.
In QT controls, the first parameter is almost always the parent object.
In HMG4 the NEW() method should be called passing the parent as the first parameter NEW( parent ), just as in QT.
But I don´t know if there is a direct way to reference the upper parent in a nested WITH / END WITH structure.
Anyone ?
If not, a control heap needs to be used, probably as a public var. If I could understand the code in window.prg, this is the way the relation between parent / child is managed, and this will ned to be moved from the CREATE() to the NEW() methods.
Pre-processor is used to do some tricks, and sometimes uses a "control heap" to keep track of the status/variable, like in tab. Unfortunately this is difficult to translate to the other programming styles.
- Rathinagiri
- Posts: 5471
- Joined: Tue Jul 29, 2008 6:30 pm
- DBs Used: MariaDB, SQLite, SQLCipher and MySQL
- Location: Sivakasi, India
- Contact:
Re: Hmg4 stylesheet
Francesco, thanks for your in depth analysis of the status of HMG 4 project.
IMHO, xBase is basically a Business Application Development Environment giving more emphasis on data than GUI elements. I am not saying that GUI is not important at all. GUI is also equally important to validate/represent the data in correct way. But to what extent? That is the question mark here.
For a powerful programmer, there is already QT with all its power.
HMG on the other hand, as rightly stated by you is a wrapper above GUI programming with its own syntax. HMG today runs well on Win32 API with its glory. But, on QT it is more powerful.
If everything can be done using C why are we having Harbour? Answer to this question will be the answer for why we want to have HMG3 syntax and functionality to be continued in HMG4 too.
Regarding your words on removal of bugs, duplicate methods, excessive memory usage by public variables I do agree.
IMHO, xBase is basically a Business Application Development Environment giving more emphasis on data than GUI elements. I am not saying that GUI is not important at all. GUI is also equally important to validate/represent the data in correct way. But to what extent? That is the question mark here.
For a powerful programmer, there is already QT with all its power.
HMG on the other hand, as rightly stated by you is a wrapper above GUI programming with its own syntax. HMG today runs well on Win32 API with its glory. But, on QT it is more powerful.
If everything can be done using C why are we having Harbour? Answer to this question will be the answer for why we want to have HMG3 syntax and functionality to be continued in HMG4 too.
Regarding your words on removal of bugs, duplicate methods, excessive memory usage by public variables I do agree.
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: Hmg4 stylesheet
Hi Francesco.
I understand that HMG3 compatibility is important and a major goal in this project.
And in fact I agree that direct inheriting or decorating is not relevant when programming in high level and if direct access to the QT object is needed the container can be accessed.
What is really bothering me is the fact that NEW() does nothing !
NEW() must instantiate an object in order to make possible to manipulate any of its properties before it is shown!
The way it´s coded now, if I do something like this:
Nothing happens, and when the window is shown oAnything:anyProperty has the default value...
I understand that HMG3 compatibility is important and a major goal in this project.
And in fact I agree that direct inheriting or decorating is not relevant when programming in high level and if direct access to the QT object is needed the container can be accessed.
What is really bothering me is the fact that NEW() does nothing !
NEW() must instantiate an object in order to make possible to manipulate any of its properties before it is shown!
The way it´s coded now, if I do something like this:
Code: Select all
oAnything := AnyControl:NEW()
oAnything:anyProperty := xAnythingDifferentFromDefault
[[]] Mauricio Ventura Faria
Re: Hmg4 stylesheet
Hi Mauricio,
I'm sorry but I don't understand your form is placed on the left top corner or in other position rather than Row := 30 and Col := 100?
Cheers
I'm sorry but I don't understand
For example: if you useNothing happens, and when the window is shown oAnything:anyProperty has the default value...
Code: Select all
formname:Row := 30 and formname:Col := 100
Cheers
Luigi from Italy
www.L3W.it
www.L3W.it
Re: Hmg4 stylesheet
Hi Rathinagiri,
I'm in agreement with you for a while ... or perhaps I don't understand HMGx scope. HMG is a GUI not a simple Xbase command like BROWSER, I think.
Ok, we must preserve (or try to preserve the most possible) compatibility with previous version on the other hand I think QT give us (for Windows and *Nix) a great opportunity. Many people give his contribute (little or big) and we are all grateful to Roberto (I'm the first) that he started HMG.
But I think there are good reasons to pause for a moment and think about what has been achieved.
For example: I try to insert StyleSheet, but I must write 2 times the same code.
I look at row and col position for an object, these data are into 2 different source (control and window) and "::oQtObject:move" the same. aBackcolor and Backcolor idem (and we must use StyleSheet to change). I think this it's not a HMG3 compatibility problem.
I am in agreement with the analysis of Francesco, but I think I understand his idea in the sense that it is good to double-check HMG4 and understand what should be retained in HMG3 style and what is not possible. In the latter case there is a problem and then Roberto will make a decision: HMG3 or HMG4.
I'm very happy to write program with HMG: simple and effective and I am willing to modify my sources, but I don't have a business. If I think about you and other, I think yes. I will not be considered HMG as an experiment. Much less HMG4. In this direction I don't think you use HMG only to have one "hard access" to the data managed by other program (ie I read a post of Marek to take data from internet connection).
This is my little opinion and I express it with great friendship and desire to contribute actively.
Cheers
I'm in agreement with you for a while ... or perhaps I don't understand HMGx scope. HMG is a GUI not a simple Xbase command like BROWSER, I think.
Ok, we must preserve (or try to preserve the most possible) compatibility with previous version on the other hand I think QT give us (for Windows and *Nix) a great opportunity. Many people give his contribute (little or big) and we are all grateful to Roberto (I'm the first) that he started HMG.
But I think there are good reasons to pause for a moment and think about what has been achieved.
For example: I try to insert StyleSheet, but I must write 2 times the same code.
I look at row and col position for an object, these data are into 2 different source (control and window) and "::oQtObject:move" the same. aBackcolor and Backcolor idem (and we must use StyleSheet to change). I think this it's not a HMG3 compatibility problem.
I am in agreement with the analysis of Francesco, but I think I understand his idea in the sense that it is good to double-check HMG4 and understand what should be retained in HMG3 style and what is not possible. In the latter case there is a problem and then Roberto will make a decision: HMG3 or HMG4.
I'm very happy to write program with HMG: simple and effective and I am willing to modify my sources, but I don't have a business. If I think about you and other, I think yes. I will not be considered HMG as an experiment. Much less HMG4. In this direction I don't think you use HMG only to have one "hard access" to the data managed by other program (ie I read a post of Marek to take data from internet connection).
This is my little opinion and I express it with great friendship and desire to contribute actively.
Cheers
Luigi from Italy
www.L3W.it
www.L3W.it
Re: Hmg4 stylesheet
I quote Rathinagiri: HMG-4 is a Business Application Development Environment.
It should help write that kind of software, not the next Word 2012.
Hmg-3 compatibility is a requirement that was requested but not always mantained ! hmg-4 was developed by some volunterees in a rush, without too much coordination other than "I do this, I do that" and you can "smell" the code for this. Preprocessor rules were not correct, features not implemented and so on. hmg-3 compatibility is not complete, and for some issues it may never be complete.
Again, sorry but I want to stress it: HMG-4 is a Business Application Development Environment and must be used only via a well defined API.
Please keep in mind that it was win-32 on hmg-3, Qt on hmg-4 but there can also be a iPad port of our programs if we can separate the programmin API from the underlying graphical engine ! This is another reason against inheriting...
I think that hmg-3 compatibility is a requirement that can be broken by necessity or impossibility to replicate behaviour.
oAnything:anyProperty := xAnythingDifferentFromDefault
actually set a DATA variable with xAnythingDifferentFromDefault and when the object :create() method is called, the Qt object is created and the variable store in the DATA variable are used to set object properties.
You may say it's a waste. and I agree.
I recall to have used ON INIT procedure to set additional properties to the objects, exactly how is done in VB6 programs I have seen. Luigi was trying to add some other callbacks on window creation, for example before and after window is show and objects created.
Please propose a solution that can save both situation: compability, removing of these DATA variables, creating objects directly.
It should help write that kind of software, not the next Word 2012.
Hmg-3 compatibility is a requirement that was requested but not always mantained ! hmg-4 was developed by some volunterees in a rush, without too much coordination other than "I do this, I do that" and you can "smell" the code for this. Preprocessor rules were not correct, features not implemented and so on. hmg-3 compatibility is not complete, and for some issues it may never be complete.
Again, sorry but I want to stress it: HMG-4 is a Business Application Development Environment and must be used only via a well defined API.
Please keep in mind that it was win-32 on hmg-3, Qt on hmg-4 but there can also be a iPad port of our programs if we can separate the programmin API from the underlying graphical engine ! This is another reason against inheriting...
I think that hmg-3 compatibility is a requirement that can be broken by necessity or impossibility to replicate behaviour.
No, it is not true what you say here.concentra wrote:Hi Francesco.
What is really bothering me is the fact that NEW() does nothing !
NEW() must instantiate an object in order to make possible to manipulate any of its properties before it is shown!
The way it´s coded now, if I do something like this:Nothing happens, and when the window is shown oAnything:anyProperty has the default value...Code: Select all
oAnything := AnyControl:NEW() oAnything:anyProperty := xAnythingDifferentFromDefault
oAnything:anyProperty := xAnythingDifferentFromDefault
actually set a DATA variable with xAnythingDifferentFromDefault and when the object :create() method is called, the Qt object is created and the variable store in the DATA variable are used to set object properties.
You may say it's a waste. and I agree.
I recall to have used ON INIT procedure to set additional properties to the objects, exactly how is done in VB6 programs I have seen. Luigi was trying to add some other callbacks on window creation, for example before and after window is show and objects created.
Please propose a solution that can save both situation: compability, removing of these DATA variables, creating objects directly.