Hmg4 stylesheet

Moderator: Rathinagiri

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:

Re: Hmg4 stylesheet

Post by Rathinagiri » Thu Mar 17, 2011 2:42 am

Nice words Francesco.

I too am interested to have a good solution with "compatibility, removing of these DATA variables, creating objects directly".
East or West HMG is the Best.
South or North HMG is worth.
...the possibilities are endless.

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 » Thu Mar 17, 2011 3:32 am

l3whmg wrote: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
Hi Luigi,

I wish to quote Roberto for the scope of HMG be it any version.
What are the main project goals ?

To keep the GUI handling as easy, elegant and clean as possible and the
library core as compact, stable and reliable as we can.

It implies, that the changes to the core will be subject to very strict test
prior tag a specific build as 'stable'.

Other of the main goals is to hide the complexities associated with the
operating system internals, allowing to the programmer, focus on his
application, instead OS technical things.
If we can achieve this that is ok.

I agree that the code now we have is buggy. Francesco is right in saying, the code is just a bundle of contributions from then and there. We have to fix, sort out, optimize and what not before releasing a beta version. In the process, we can't omit compatibility and the basic goal of HMG being simple, stable and reliable. That's all.

Let us join together and work for that. I am sure we can definitely achieve. :)
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 » Thu Mar 17, 2011 9:58 am

Hi.
l3whmg wrote:your form is placed on the left top corner or in other position rather than Row := 30 and Col := 100?
mrduck wrote: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.
Sorry people ! I messed thinks up...
This were happening when I tried to move common properties and methods from the controls to the parent class (CONTROL). I get back to SVN and things works again.
Really sorry !
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Thu Mar 17, 2011 3:10 pm

Hi friends :D
I have done some modification to my HMG experiment. I want try to use some Concentra's idea and preserving HMG3 concept.

The first program (pgm001.prg) is like current HMG4 style. The second program (pgm002.prg)...take a look in "FrmOnInit" function.

Normally we can use <FormName>:<ControlName>:Title := "some value".
I have update my code and now I can use <FormName>:QtObject:setWindowTitle( "I can change form title" ) where "QtObject" is a QT object and "setWindowTitle" is a QT method for this object. This is an experiment but I don't like very mutch.

I'm in agreement with Roberto, Rathinagiri and MrDuck about compatibility, future, etc.
Anyway, I want to renew the invitation to reflect on the source code written so far.


Regardless of ability to use the QT object directly, check the source code I wrote (hmg-xxxxx.prg).
  • . You'll notice that both object "windows" that object "label " use some functions inherit from the same source baseobject. This should be a must for many objects HMG4
  • . I create QT object in New method.
  • . I have two Parent possibility. currentParent : like HMG4 but the first is desktop and defaultParent: this must be desktop to have a reliable reference.
  • . I introduce "windows:" public: in this way (I hope) we can overcome the problem of so many variables that are declared public (see formname:control:value in static functions)
I have also discovered this Qt function "QApplication():addLibraryPath( <pathname> )"
This feature allows you to add, programmatically, one or more paths, allowing the search for files in these folders.
In particular, it is useful to avoid the use of the file "qt.conf". This is the sample usage (must be insert in QT starter):

Code: Select all

   LOCAL cPath, cFile, cExt
   LOCAL QtPluginPath
   hb_FnameSplit( hb_Progname(), @cPath, @cFile, @cExt )
   QtPluginPath := cPath + "Qt" + hb_ps() + "plugins"
   QApplication():addLibraryPath( QtPluginPath )
ie <ExePath>\Qt\Plugins\ImageFormats\qico4.dll
In this way you can put plugins dll in <ExePath>\Qt\Plugins and Qt try to find here. qt.conf it's not required

That's all folk. :mrgreen:
Now, I will return to focus on some HbQt/HMG4 test.

Cheers ;)
Attachments
MyHMGui.zip
my hmg pov
(519.61 KiB) Downloaded 55 times
Luigi from Italy
www.L3W.it

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 » Thu Mar 17, 2011 3:24 pm

Thanks Luigi. I will look into it.
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 » Fri Mar 18, 2011 10:32 am

Hi people!

One of the difficulties I found was "How do I know the parent object ?".
Ok, since the objects are coded basically using a WITH OBJECT / END nested structure like this:

Code: Select all

With oObject1
   .
   .
   With oObject2
      .
      // Need to point to oObject1, the parent.
      // without knowing its name.
      .
      .
   End with
   .
   .
End with
If the lib XHB is linked, there is a function that returns the previous object in the nested WITH OBJECT / END structure: HB_QWith().
HB_QWith() without parameters returns the current object.
HB_QWith(1) returns the previous in the stack, HB_QWith(2) another level down, and so on.
So, it´s possible to reference the parent object without knowing it´s name using:

Code: Select all

With oObject1
   .
   .
   With oObject2
      .
      :oParent := HB_QWith(1)
      .
      .
   End with
   .
   .
End with
I think that this can help in instantiating the controls in the NEW() method.
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Fri Mar 18, 2011 11:17 am

Hi Mauricio,
I'm sorry I don't understand your problem. I try to give my knowledge.

First: take a look in window.prg in New method

Code: Select all

METHOD New() CLASS WINDOW

   ::oDefaultParent := Self

   RETURN Self
When you create a form from this moment it is the deault parent (::oDefaultParent its a shared value)

Second: take a look in control.prg in New method

Code: Select all

/*----------------------------------------------------------------------*/
//                                Methods
/*----------------------------------------------------------------------*/

METHOD New() CLASS CONTROL

   IF !::lGridCellFlag
      ::nObjectCounter++
      ::oParent := ::oDefaultParent
If I create a label its parent becomes the form previously created (::oParent := ::oDefaultParent )

If you need th QtObject of the Label object, you can give with ::oQTObject. If you want tha parent QT object you can give with ::oParent:oQtObject.

Attention: when "end window" is invoked this form method is invoked

Code: Select all

METHOD EndWindow() CLASS Window

   ::oDefaultParent := NIL

   RETURN NIL
Why this? To end the parent dependencies. In this way, the creation of a new form will make himself the new parent (take a look to the top of this post).

I hope I've given you a correct and consistent information with your problem.

Cheers
Luigi from Italy
www.L3W.it

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

Post by mrduck » Fri Mar 18, 2011 5:31 pm

Luigi
it is to solve anothe type of problem (preprocessor)

Post Reply