About HMG.4 Samples...

Moderator: Rathinagiri

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Re: About HMG.4 Samples...

Post by Roberto Lopez » Wed Nov 30, 2011 6:59 pm

Francesco, Luigi,

Ok.

Before going further with splitting, I'll start working with semi-oop samples, trying to keep it working and at the same time, still clean and easy.

When this work be finished, we will take a final decision about how are they presented to the users.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Thu Dec 01, 2011 1:54 am

Hi,

I've was thinking on some rules for the non-OOP samples. This is a draft only.
Intro:

To simplify things, we should have two syntax types demos only (at least, at the begining): OOP and Semi-OOP (new style, one line per property for object definition). We can later, think on xBase (@..) and HMG3 compatible samples.

Semi-OOP samples rules:

1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.

2. The windows variables should be declared using MEMVAR.

3. We should use the ':' operator (instead of '.').

4. An error handler should be invoked by default to avoid including hbqt_errorsys() call on every demo. IMHO, this requirement in samples used to teach the basics, generates the idea of complexity.

5. As mentioned in the intro, only the new definition style (one property per line) should be used.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

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

Post by mrduck » Thu Dec 01, 2011 6:36 am

My ideas, we are discussing.... :-)

1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
I'd like to keep a separation between hmg3 compatibility layer (that may be abandoned in 2022 :-) ) and hmg4... There are already and there will be more in the future, different behaviours that we need to ddefferentiate.
I will also try to educate users to use hbmk2... it's really easy !
2. The windows variables should be declared using MEMVAR.
I suppose it is to avoid -w3 ?
Roberto Lopez wrote: 3. We should use the ':' operator (instead of '.').
Should be MANDATORY the use of : and BANNED the use of .

How it is now, ferase( "pippo.txt" ) is translated by preprocessor to ferase( "pippo:txt" )

If we complete hmg3.ch we may remove the default . => : command and rely on DECLARE WINDOW #xcommands
4. An error handler should be invoked by default to avoid including hbqt_errorsys() call on every demo. IMHO, this requirement in samples used to teach the basics, generates the idea of complexity.
Ok, I agree. I propose to add a
INIT PROCEDURE to misc.prg
5. As mentioned in the intro, only the new definition style (one property per line) should be used.
I see from the code I could gather that xBase syntax is quite widely used...

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Thu Dec 01, 2011 12:29 pm

mrduck wrote: 2. The windows variables should be declared using MEMVAR.

I suppose it is to avoid -w3 ?
The idea is that semi-oop does not require any special (different) way of build.
mrduck wrote: Should be MANDATORY the use of : and BANNED the use of .
We agree.
mrduck wrote: 4. An error handler should be invoked by default to avoid including hbqt_errorsys() call on every demo. IMHO, this requirement in samples used to teach the basics, generates the idea of complexity.

Ok, I agree. I propose to add a
INIT PROCEDURE to misc.prg
It's ok for me.

I'll wait for it.

mrduck wrote: 5. As mentioned in the intro, only the new definition style (one property per line) should be used.

I see from the code I could gather that xBase syntax is quite widely used...
I'm not sure the meaning of this, but my idea is to focus in the syntax that will encourage the developers to use (OOP and Semi-OOP/one line per property).

The work on xBase samples should have a minor priority and we should take care of them later.

Anyway, I'll rethink this before starting work.

I'll not commit anything without the full agreement of the main developers.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

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

Post by l3whmg » Fri Dec 02, 2011 8:32 am

Hi Roberto, Francesco and other.....

I quoted MrDuck, but not to replay only to him
mrduck wrote:1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
I'm sorry I don't understand what is "any compatibility switch". Do you think about "-DHMG3" or about "-w3, -es2, -strip"?
mrduck wrote:2. The windows variables should be declared using MEMVAR.
Do you think about Xbase command style. With mixed OOP/Xbase can be, but... with OOP there isn't reason.

Code: Select all

CLASS MyClass
DATA MyWindow INIT NIL
METHOD New(...) CLASS MyClass
::MyWindow := MAINWINDOW():New(...)
etc...
mrduck wrote:3. We should use the ':' operator (instead of '.').
I'm in agreement with you: for all
mrduck wrote:4. An error handler should be invoked by default to avoid including hbqt_errorsys() call on every demo. IMHO, this requirement in samples used to teach the basics, generates the idea of complexity.
.
I'm in agreement with you. But, please, must be manageable and it must not include any function other than error handling.
mrduck wrote:5. As mentioned in the intro, only the new definition style (one property per line) should be used.
Total in agreement. It's similar to "alternate syntax" and very manageable.

About compilation switch: please, take care of "-w3". Eg. many times I found, in my programs, a wrong usage of var. I think this switch can avoid "unexpected" problem. On the other hand, as I write in other thread, I think we must use .hbp and .hbc file for demos not only for library. HBMK2 is a "standard" command of Harbour compiler: we must take care of this, use it and propose a proper use of the building configuration files. HbIde (and I think HmgIde) take care of these file to handle project configuration.
IMHO: if I can't create a program/library without any warnings (obviously without errors), for me it is/ can be unreliable.

Cheers
Luigi from Italy
www.L3W.it

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Sat Dec 03, 2011 6:27 pm

l3whmg wrote:
mrduck wrote:1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
I'm sorry I don't understand what is "any compatibility switch". Do you think about "-DHMG3" or about "-w3, -es2, -strip"?
I mean that Semi-oop in HMG.4 should work without using -DHMG3 or hmg_compatibility() or any other artifact. These things should be required only for HMG3 compatibility.
mrduck wrote:2. The windows variables should be declared using MEMVAR.
Do you think about Xbase command style. With mixed OOP/Xbase can be, but... with OOP there isn't reason.
[/code]

I'm talking about the forst case, of course.
mrduck wrote:3. We should use the ':' operator (instead of '.').
I'm in agreement with you: for all
mrduck wrote:4. An error handler should be invoked by default to avoid including hbqt_errorsys() call on every demo. IMHO, this requirement in samples used to teach the basics, generates the idea of complexity.
.
I'm in agreement with you. But, please, must be manageable and it must not include any function other than error handling.

I'm only asking for it.
mrduck wrote:5. As mentioned in the intro, only the new definition style (one property per line) should be used.
Total in agreement. It's similar to "alternate syntax" and very manageable.

About compilation switch: please, take care of "-w3". Eg. many times I found, in my programs, a wrong usage of var. I think this switch can avoid "unexpected" problem. On the other hand, as I write in other thread, I think we must use .hbp and .hbc file for demos not only for library. HBMK2 is a "standard" command of Harbour compiler: we must take care of this, use it and propose a proper use of the building configuration files. HbIde (and I think HmgIde) take care of these file to handle project configuration.
IMHO: if I can't create a program/library without any warnings (obviously without errors), for me it is/ can be unreliable.

Cheers[/quote]

I've redesigned IDE to use hbmk2 instead is internal make tool, many time ago so, we agree on this.

Anyway, as I've already said, I'll not start the work on the samples right now.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

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

Post by l3whmg » Sat Dec 03, 2011 6:56 pm

Great Roberto.
Now it's more clear for me. In these days I'm little busy....After two/three days I'm free and I can do some work described on this thread in agreement with all.
You or Francesco can choose where I can start or what I can do....
Cheers
Luigi from Italy
www.L3W.it

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

Post by mrduck » Sat Dec 03, 2011 11:02 pm

Hi Roberto,
Roberto Lopez wrote: I mean that Semi-oop in HMG.4 should work without using -DHMG3 or hmg_compatibility() or any other artifact. These things should be required only for HMG3 compatibility.
here I need to explain a bit.

semi-oop works without -DHMG3 and without hmg_compatibility( .T. ) if we follow "HMG4 rules".

Example:
DEFINE WINDOW Test

In HMG3 and 4 Test is a public variabile. In HMG4 is an OBJECT. And so we can call methods directly
Test:setFocus() is the standard harbour way.
Test.setFocus() is supported since we preprocess . => :
Test.setFocus NEEDS -DHMG3

With this #define we force loading of hmg3.ch where a very clever, compile-time directive creates a series of xtranslate specific to Test window !
I ported hmg3.ch this summer from hmg3 source code. Original file was translating hmg3 false oop to helper functions like doMethod, Set/GetProperty etc etc that in the end simulated an OOP environment. I started to convert (I did not complete) to pure OOP calls.

Code: Select all

    #xtranslate <w> . \<p:Activate,Center,Release,Maximize,Minimize,Restore,Show,Hide,SetFocus,Print,Capture> \[()\] => <w>:\<p\>() ;;
Perhaps we should evauate if it is possible to complete the porting and then make these xtranslate mandatory so that we can drop the . => : conversion that has some bad side-effects

From what I have seen in some hmg3 code sent to me, sometimes doMethod and Set/GetProperties are used directly in the code, so I needed to create some mockups for them...

Unfortunately some of the hmg3 functions are very complex, with nested IFs, depending on object type, numer of parameters etc etc. Up to now I have something simple like:

Code: Select all

FUNCTION GetProperty( cWindow , cControl , cProperty, nIndex )

   IF pcount() == 3
      RETURN &cWindow:&cControl:&cProperty
   ELSEIF pcount() == 4
      RETURN &cWindow:&cControl:&cProperty( nIndex )
   ENDIF

   msgQuit( "getProperty called with "+str(pcount())+" parameters not implemented" )
RETURN NIL
but probably we may solve in some other way but an hmg3 core code expert is needed.... or we may request programmers to change ther source code !!!

About hmg3_compatibility.

Imagine a form F with a tab TAB with a tabpage TP with a button BTN.

In hmg3 you can access BTN directly from the form with:
F.BTN.setFocus

In hmg4 you must access BTN with:
F:TAB:TP:BTN:setFocus()

It's longer but it allows to have buttons with the same name in different tabs. Trust me, it may be needed....

Since it breaks compatibility, if we require STRICT hmg3 compatibility (if programmers refuse to adapt their programs) the objects in a tabpage, in a toolbar, in a menupopup, a contextmenu and dropdownmenu are also "added" to their MAIN/CHILD/MODALWINDOW or DIALOG. So F:BTN:setFocus() works in hmg4...
The other point where the flag is used is in combobox, where height in Qt has a completely different meaning respect to win32....


So, in conclusion, we should take a very strong decision: in HMG4 what is "official", "supported", "deprecated".

IF (ipotesis) OOP is official, semioop supported and xbase syntax deprecated we may start to shuffle hmg[3].ch contents to separate the 3 programming styles... but a couple of questions:

Code: Select all

release window Test
is semioop or xBase ? I think it is both....

Code: Select all

Test.setFocus
is semioop or xBase ? It is semioop while SETFOCUS n TO w is xbase (not implemented in hmg4)

... message is too long... I stop here :-))))

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

Post by mrduck » Sat Dec 03, 2011 11:46 pm

mrduck wrote: IF (ipotesis) OOP is official, semioop supported and xbase syntax deprecated
Not deprecated, let's say "best effort"...

"best effort" means that there is no guarantee that a hmg3 program written in xbase style will compile errorlessy in hmg4...

as an example

Code: Select all

SETFOCUS n TO w 
is not present yet in hmg4 and if someone uses it in his code he can:
- depend on others asking the forum to implement
- doing himself, changing his source code to oop style (w:setfocus() - I don't know what "n" is for) or creating the define and posting it on the forum


I will commit in next days code for setting QRegExpValidators to a TEXTBOX. It is a feature specific to Qt that is not easily backportable to hmg3... should I add semioop syntax ? and expand textbox xbase syntax ?

Code: Select all

// OOP
WITH OBJECT t1 := textbox():New()
   .....
   :validator := "\d{0,5}"  // accept from 0 to 5 digits
END

// semioop can be implemented since we said it is "supported" state
DEFINE TEXTBOX t1
  ....
   VALIDATOR "\d{0,5}"
END

// xBase I DON'T want to implement.... but it can be, since it is "best effort" state...
@ x,y TEXTBOX ....  VALIDATOR "\d{0,5}" .....

What do you think ?

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Sun Dec 04, 2011 10:14 pm

Francesco,

Your post deserves a more deep answer from me, but I'm pretty busy now to do that.

I'll just clarify a little something...

When I'm talking about new style semi-oop in HMG.4 I'm talking about this:

Code: Select all

#include "hmg.ch"

MEMVAR oWindow1

FUNCTION Main

   DEFINE MAINWINDOW oWindow1
      Row    10
      Col    10
      Width  400
      Height 400
      Title  'Nice OOP Demo!!!'
      OnInit oWindow1:Center()

      DEFINE BUTTON oButton1
         Row     40
         Col     40
         Caption 'OOP Button!!!'
         OnClick ButtonClick()
      END BUTTON

   END WINDOW

   ACTIVATE WINDOW oWindow1

RETURN NIL

/*----------------------------------------------------------------------*/

PROCEDURE ButtonClick()

   MsgInfo( oWindow1:oButton1:Caption , 'Standard Send Operator' )

RETURN
The two keys that makes it 'Semi-OOP' are the following:

1. The window objects created via DEFINE WINDOW are automatically made public at definition.

2. The windows control's created via:

DEFINE <ControlType> <TagReference>

are accessed in the form

<oWindow>:<TagReference>:<Property>

- The HMG3 ways (GetProperty(), SetProperty(), DoMethod(), '.' send operator) should be under the 'compatibility mode' umbrella. The use of special switches, defines and function calls are required to make it available.

- Returning to samples, IMHO, to avoid confusing the users with too many syntax modes, we should focus on the two 'modern' ways: OOP and new Semi-OOP. The other two modes (@... Commands and HMG3 compatible) should have a minor priority/different place from the main samples tree.

- IMHO, this new Semi-OOP, is simpler than the HMG3 one, because the one line per property window definitions and because it is more closer to OOP programmers, not loosing its easiness.

- The only thing that disturbs me a little, is the MEMVAR requirement for the window object variable (it makes the code a little dirty) but I understand its need.

- IMHO, HMG.4 should has its first beta when it be ready itself, without regarding the status of HMG3 compatibility. A high degree of compatibility will be a very long road and it should not disturb HMG.4 release cycles.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

Post Reply