Important: forms handling evolution, child form

[l3whmg]

Hi friends.
In these days, me and Francesco worked a lot on the window management.

The first good news is that - now - we also have and use the CHILD type; its behavior is like to HMG3.
Another goal achieved was the ability to better manage the forms relationships, usage of forms child of forms.
A more efficient control at creation time and the ability to check "immediately" possible anomalies.
Finally, a more efficient procedure for closing forms.

To achieve these goals, it became necessary to know the type of form during object creation; in other words, within New() method.
This will change the way to write programs in OOP style while, in the XBase commands style, there will be no problems.

1) Structure, relationship.
With HMG4 previous version all windows were (by default) at the same level. This can be a scheme

Code: Select all

                             <toplevel OR ::s_oToParent>
                                        |
      |---------------|-----------------|----------------|---------------|
   <Form1>    -    <Form2>    -    <MainForm>    -    <Form3>    -    <Form4>

With this built we can have:

Code: Select all

                             <toplevel OR ::s_oToParent>
                                        |
                                        |----------------|
                                   <MainForm>    -    <Form1>
                                        |
      |---------------|-----------------|----------------|---------------|
   <Form2>    -    <Form3>    -      <Form4>     -    <Form5>    -    <Form6>
                                                         |
                                                      <Form7>

2) Rules

• 2.1) Only one time can be used a valid character reference to naming a form. ie if "MyFormName" is assigned to form-1, "MyFormName" can't be used to naming form-2
  2.2) Only one WND_MAIN form type can exists in a program.
  2.3) A WND_MAIN form type must be created before any other form types.
  2.4) WND_MAIN parent ALWAYS is the toplevel.
  2.5) By default: any new form has, as its parent, WND_MAIN
  2.6) A form (not WND_MAIN) can be child of another form

3) were born these classes:

• - MAINWINDOW() to create a WND_MAIN form: the most important form of your application. Only one WND_MAIN can exists in a program and must be created before any other form types. This form will always child of the application in other words "::s_oTopParent". The shared var. ":: s_oMainwindow" will contains the object and method HMGAPP():MainWindow() can be used to know value, not to set.
  - MODALWINDOW() to create a WND_MODAL form; its behavior is unchanged. When activated a form of this type, you can only work on itself. To use other forms, including MAINWINDOW, you must proceed with its closure.
  - CHILDWINDOW() to create a WND_CHILD form; its characteristic is to be directly subordinated to the MainWindow. If the MainWindow is iconified ChildWindow also automatically will be and, on the status bar, you will see only the MainForm.
  - WINDOW() to create a WND_STANDARD form; its characteristics are the current ones.

4) OOP syntax.
Because of these innovations, you can not use this syntax:

Code: Select all

      WITH OBJECT oVar := WINDOW():New(......
          TYPE [WND_MAIN | WND_STANDARD | WND_MODAL | ..... ]   <====

You'll need to use

• * WITH OBJECT oVar := MAINWINDOW():New( ["name"][, parent] ) to create a WND_MAIN form
  * WITH OBJECT oVar := MODALWINDOW():New( ["name"][, parent] ) to create a WND_MODAL form
  * WITH OBJECT oVar := CHILDWINDOW():New( ["name"][, parent] ) to create a WND_CHILD form
  will require following syntax to create a WND_STANDARD form
  * WITH OBJECT oVar := WINDOW():New( ["name"][, parent] )

The TYPE() method, still provided of the option "SETGET", will only used to know the type of the form; eg. nFormType := Form:Type()

5) XBase commands syntax.
In addition to the HMG3 commands, have been introduced these other

• * DEFINE MAINWINDOW ReferenceName to create a WND_MAIN form
  * DEFINE MODALWINDOW ReferenceName to create a WND_MODAL form
  * DEFINE CHILDWINDOW ReferenceName to create a WND_CHILD form
  will require following syntax to create a WND_STANDARD form
  * DEFINE WINDOW ReferenceName

6) Relationship, controls
By default, a "WND_MODAL", "WND_CHILD" or "WND_STANDARD" form will be child of a "WND_MAIN" form.
This involves a longer path to reach its children.
The following syntax "HMGAPP():StandardFormName:ControlName" will not be valid; instead, you'll need usage of
"HMGAPP():MainFormName:StandardFormName:ControlName"
but, both style "OOP" that "XBase commands" programs will be create a var, you will have:

Code: Select all

       LOCAL oMoDalForm
       ........
       WITH OBJECT oModalForm := MODALWINDOW():New()
       ........
          WITH OBJECT LABEL():New( "label1" )
       ........

       oModalForm:Label1:Visible := .F.

7) Autorelease
With Hmg3: when set to OFF /. F. (default on /. T.) and will be hold the button [X], the form will be hidden.
Any onRelease block will be executed when the Release() method will be used or when the MAINFORM will be closed.
the method HMGAPP():WindowsShowAll() was created to show all hidden forms.

Obviously, they will have further tests and improvements. everyone's cooperation is appreciated.

Please: don't do commits; wait my updating. I'm started from built 759. Many thanks
2011-10-21 I have done commit. Topic update 2011-10-22

On the other hand, I will wait HMG4 updating because I have introduced usage of QLibraryInfo class, to handle values from qt.conf file about plugins and translations paths. For this reason, ABOUT HARBOUR COMPILER MINIMUM VERSION REQUIRED WILL BE Harbour 3.1 built r17076

I'm not sure to be able to change every demo; before compile and run take a look and send a message if you found anomalies related to this evolution.

Remember:
A) the first form must be a MAIN WINDOW:
- With OOP style this syntax can be used: with object [localvar :=] MAINWINDOW()
- With XBase commands style this syntax can be used:
DEFINE WINDOW name
.....
MAIN

B) other forms in according with new classes using OOP style or right value with DEFINE command using XBase commands style

Best regards

[Rathinagiri]

Very interesting Luigi.

[tave2009]

Hola Luis,
Una sugerencia, siempre y cuando se pueda, ¿las ventanas
podrian dejar de tener nombres?, obviamente el programa deberia hacerlo oculto a nuestro ojos, por ejemplo: con un arreglo dinamico.
Te dejo la inquietud.
Saludos
Walter.
PD. Hace uno cuantos años atras habia una libreria en modo consola y con el viejo Clipper (SOSO's.lib) o algo parecido, estaba alojada en el repositorio de Phil Barnett, que hacia esto

Google translation
Hello Luigi,
One suggestion, as long as possible, the windows
could fail to have names?, obviously the program should do it hidden from our eyes, for example, with a dynamic array.
I leave the concern.
regards
Walter.
PD. A few years ago there was a library back in console mode and with the old Clipper (SOSO's. Lib) or something, was housed in the repository of Phil Barnett, towards this.

[l3whmg]

Hi Tave2009.
I'm not sure to understand you. Anyway I will try to answer.
First of all: naming object give us a great way to find them in our program.

Every "object" must have a name to have a solid reference and to give a good way to find it. On the other hand, a numeric array "can be" a solution, but it requires more attention and a good management; with a simple reference and usage of Hash table we have solved a lot of problems (this is my little opinion).

A very, very little example with Array
FormsArray[1,1] := "Mainform", FormArray[1,2] := Object or other
FormsArray[n,1] := "FormName....", FormArray[1,2] := Object or other

In you program do you prefer usage of: a) "Form[1].Control[1]" or b) "Mainform.LabelName" ? I think b)

But with array, to find a form, I need to do (this is an example )

Code: Select all

FOR nX := 1 TO LEN( FormsArray)
   IF ALLTRIM(UPPER(FormsArray[nX,1])) == ALLTRIM( UPPER(NameToFind) )
      RETURN ALLTRIM(UPPER(FormsArray[nX,1]))
   ENDIF
NEXT nX
RETURN NIL

And now, please, you think about creation, deletion and so on about: form, label, ecc.
On the other hand, your application has childs (forms), every child has childs (forms, label, etc).

Second we must respect HMG3 rules to have the better compatibility. With HMG3 the syntax is: "DEFINE WINDOW ThisIsFormName" and in your program you must use "ThisIsFormName.ThisIsControl.ItsValue".
With HMG4, with usage of OOP, there is a "little" difference: you can have an object at program level; so you can use this syntax: "oMyForm := WINDOW():New()" and it's not required to have a reference name.... but your "reference" is oMyForm

So, to preserve HMG3 but to handle a reference, HMG4 was born in the same way: naming objects. A big difference between HMG3 and HMG4-OOP is that you can omit this reference and use your class var to store the object.

Code: Select all

CLASS MyClass
DATA oMyForm
............
METHOD New() MyClass
oMyForm := WINDOW():New()
..........

As you can see, I don't use any reference.
The great difference is: you can "call" your class a lot of time. Every time it has an internal reference created in this way "HMG_OBJECT_number" where number is from 1 to infinite and you can avoid the use of the name.

I hope my answer is satisfactory and suitable.

Cheers

[tave2009]

Hello,
Yes, your answer was clear and satisfactory.
regards
Walter