Hmg4 stylesheet

Moderator: Rathinagiri

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

Re: Hmg4 stylesheet

Post by concentra » Wed Mar 16, 2011 10:53 am

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...
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Wed Mar 16, 2011 11:30 am

Many thanks. I'll read
Luigi from Italy
www.L3W.it

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

Post by l3whmg » Wed Mar 16, 2011 3:44 pm

Hi Mauricio,
I study your idea and about this
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.
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:

Code: Select all

QtDesktop
     |-->Form1
     |-->Form2
             |-->Form3
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
Luigi from Italy
www.L3W.it

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

Post by mrduck » Wed Mar 16, 2011 5:52 pm

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

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

Post by mrduck » Wed Mar 16, 2011 5:57 pm

concentra wrote:Hi
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)
I will assume that this is the syntax preprocessed with the hmg.ch and converted to the "with object" statements .
Yes, it is.
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.
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.

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.

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

Post by Rathinagiri » Wed Mar 16, 2011 6:43 pm

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.
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

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

Post by concentra » Wed Mar 16, 2011 7:05 pm

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:

Code: Select all

oAnything := AnyControl:NEW()
oAnything:anyProperty := xAnythingDifferentFromDefault
Nothing happens, and when the window is shown oAnything:anyProperty has the default value...
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Wed Mar 16, 2011 8:56 pm

Hi Mauricio,
I'm sorry but I don't understand
Nothing happens, and when the window is shown oAnything:anyProperty has the default value...
For example: if you use

Code: Select all

formname:Row := 30 and formname:Col := 100
your form is placed on the left top corner or in other position rather than Row := 30 and Col := 100?

Cheers
Luigi from Italy
www.L3W.it

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

Post by l3whmg » Wed Mar 16, 2011 9:38 pm

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
Luigi from Italy
www.L3W.it

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

Post by mrduck » Wed Mar 16, 2011 11:56 pm

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.

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:

Code: Select all

oAnything := AnyControl:NEW()
oAnything:anyProperty := xAnythingDifferentFromDefault
Nothing happens, and when the window is shown oAnything:anyProperty has the default value...
No, it is not true what you say here.
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.

Post Reply