HMG4: start, quit, resource, localized

Moderator: Rathinagiri

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

Re: HMG4: start, quit, resource, localized

Post by l3whmg » Sun Jul 03, 2011 1:09 pm

Hi to everyone,
I've done commit 655 about use of "__cActiveWindow", THISWINDOW, THIS.
Now we also have "s_oTopParent" (it's hmgapp), this object have its QtObject( it's Desktop() ).
To have compatibility with HMG4 parent system I must add something in hmgapp.
I compile and check "samples/window.main/demo3.prg". I think work fine.

This is changelog
2011-07-03 15:00 UTC+0100 Luigi Ferraris ( <luigi at l3w.it> )
* samples/demo_3.prg
! check and fixed source code

! include/hmg.ch
! fixed THISWINDOW in according with current usage
! fixed THIS in according with current usage

* source/window.prg
! Fixed a little problem within focusedcontrol caused by previous commit
* when create a new window without parent and it's not a child,
his parent now it's "s_oTopParent"
- removed "__cActiveWindow"

* source/hmgapp.prg
+ add "oQtObject", "aControls" data var to have compatibility with HMG parent system
+ add AddData() method to have compatibility with HMG parent system
* activate use of "s_oTopParent" and "oQtObject"
+ CurrHmgWin() method to know current Hmg window

* source/globshared.prg
* add "s_oCurWindow", "s_oTopParent" shared vars
Best regards
Luigi from Italy
www.L3W.it

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

Post by Rathinagiri » Sun Jul 03, 2011 4:31 pm

Thanks Luigi. I will check this tomorrow.
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 » Mon Jul 04, 2011 4:50 pm

Hi Luigi !
l3whmg wrote:Who write but why "Must be an empty block"?
That was me !
Some time ago I introduce this in order to simplify some code that involved bOnRelease.
But reviewing the current code this seems not to be true/needed anymore.
[[]] Mauricio Ventura Faria

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

Post by concentra » Mon Jul 04, 2011 5:14 pm

Hi Luigi.
l3whmg wrote:Hi friends, I do a new commit with the second part of my job.
Great job on localizing !
Last week I was investigating a problem with when closing a window, the associated loop wasn´t closed properly.
And your changes just fixed the problem !
But at that time I also found a problem related to this and didn´t fixed it.
The problem:
When multiple no-modal windows are open, if the main one is closed, all other windows are automatically closed.
When all windows are modal no problem at all.
This is because when the main window is closed it calls HMGAPP():Quit() and quit the application.
Test this code:

Code: Select all

#include "hmg.ch"

FUNCTION Main()

   LOCAL oMainWindow
   LOCAL oButton1
   LOCAL oButton2

   HbQt_ErrorSys()

   WITH OBJECT oMainWindow := Window():New()
      :Width  := 200
      :Height := 400
      :Title  := "Tests"
      :OnInit := {|| ( MsgInfo(oMainWindow:oButton1:Caption) )}

      WITH OBJECT oButton1 := Button():New("oButton1")
         :Row     := 40
         :Col     := 10
         :Width   := 180
         :Caption := 'Click to Open Child Window'
         :OnClick := { || ChildWindow() }
      END WITH

   End   // oMainWindow

   oMainWindow:Activate()

   oMainWindow := NIL

   RETURN




FUNCTION ChildWindow()

   LOCAL oChildWindow
   LOCAL oButton3

   WITH OBJECT oChildWindow := Window():New()
      :Width  := 400
      :Height := 300
      :Title  := "Child Window"
      :OnInit := { || oChildWindow:Center() }

      WITH OBJECT oButton3 := Button():New()
         :Row     := 40
         :Col     := 10
         :Width   := 380
         :Caption := 'Click to Close Child Window'
         :OnClick := { || oChildWindow:Release() }
      END WITH

   End   // oChildWindow

   oChildWindow:Activate()

   oChildWindow := NIL

RETURN NIL
We probably need a more complex release control, checking if the current window been closed is the last one and if so calling :quit().
A possible solution is to define a shared var used as an opened windows counter, adding when new windows are created, subtracting while closing and testing if 0 (zero) when quitting.

Any suggestions ?
[[]] Mauricio Ventura Faria

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

Post by mrduck » Mon Jul 04, 2011 5:23 pm

concentra wrote: We probably need a more complex release control, checking if the current window been closed is the last one and if so calling :quit().
A possible solution is to define a shared var used as an opened windows counter, adding when new windows are created, subtracting while closing and testing if 0 (zero) when quitting.

Any suggestions ?
From qt docs:
If the last top-level window is closed, the QApplication::lastWindowClosed() signal is emitted.

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

Post by concentra » Mon Jul 04, 2011 5:34 pm

l3whmg wrote:On the other hand, you can look inside window.prg: I've fixed a lot of code when value must be assigned adding check of VALTYPE. I think this must be a must in every source.
Luigi, I will disagree with this.

At first I coded like you said, verifying types but later I stopped.
In my point of view when an invalid parameter is passed an error must be generated, just like Clipper/Harbour do.

Checking types can mask coding errors that will be hard to see because the typing check hides them.
Simply testing if the parameter type is valid in order to avoid an error can cause problems while debugging problematic code.
No one wants to pass wrong types while coding, but is can happen accidentally and the sooner the error the sooner the fix.

For example: when coding an application, a wrong var type is passed as parameter and when testing, this may be correct. But the behavior of the application is not as expected because I thought I passed a valid parameter and this was not true... And probably I will send the code to the final user and he will find the problem. Users do not like this !!!

It is hard to debug such an error because the lib accepts this and did not send a message about.
That´s why Clipper , Harbour and other languages send error messages when a parameter type is not as expected.

This is my opinion, but must be discussed here and explicitly defined in the coding rules.
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Mon Jul 04, 2011 5:37 pm

Hi to everyone.
MrDuck it's right.
On the other hand, I have write in my post: we have to options: 1) use of HMGAPP():Quit() when main window is closed (via connected event) or 2) programmaticaly inside program. In this moment, I prefer to respect HMG3 style.

Remember: for HMG3 it's mandatory to have a WND_MAIN form open and active.

With HMG4 we have a new future: modal or child(???) can be opened witho main form.

Please take a look here: viewtopic.php?f=32&t=2016
I have problems with HMG.CH. I'm rewriting a lot of commands!

Best regards.
Luigi from Italy
www.L3W.it

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

Post by concentra » Mon Jul 04, 2011 5:37 pm

removed...
[[]] Mauricio Ventura Faria

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

Post by l3whmg » Mon Jul 04, 2011 5:39 pm

Hi Mauricio.
About check VALTYPE I'm in agrrement with if we have now a valid errorsys. There are a lot of errors to check, but IMHO we must have an usable HMG4.

Cheers
Luigi from Italy
www.L3W.it

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

Post by mrduck » Mon Jul 04, 2011 5:43 pm

concentra wrote: No one wants to pass wrong types while coding, but is can happen accidentally and the sooner the error the sooner the fix.
I vote to raise an error, via the harbour error system so we can trap it.

Please note that in several cases we also need to accept NIL as a valid value, like on OnRelease. We may need to set a codeblock and to reset it... resetting can be setting {||.T.} but is it better to set NIL...

Post Reply