About HMG.4 Samples...
Moderator: Rathinagiri
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About HMG.4 Samples...
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.
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)
Roberto
(Veritas Filia Temporis)
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About HMG.4 Samples...
Hi,
I've was thinking on some rules for the non-OOP samples. This is a draft only.
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)
Roberto
(Veritas Filia Temporis)
Re: About HMG.4 Samples...
My ideas, we are discussing....
I will also try to educate users to use hbmk2... it's really easy !
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
INIT PROCEDURE to misc.prg
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.1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
I will also try to educate users to use hbmk2... it's really easy !
I suppose it is to avoid -w3 ?2. The windows variables should be declared using MEMVAR.
Should be MANDATORY the use of : and BANNED the use of .Roberto Lopez wrote: 3. We should use the ':' operator (instead 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
Ok, I agree. I propose to add a4. 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.
INIT PROCEDURE to misc.prg
I see from the code I could gather that xBase syntax is quite widely used...5. As mentioned in the intro, only the new definition style (one property per line) should be used.
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About HMG.4 Samples...
The idea is that semi-oop does not require any special (different) way of build.mrduck wrote: 2. The windows variables should be declared using MEMVAR.
I suppose it is to avoid -w3 ?
We agree.mrduck wrote: Should be MANDATORY the use of : and BANNED the use of .
It's ok for me.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
I'll wait for it.
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).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...
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)
Roberto
(Veritas Filia Temporis)
Re: About HMG.4 Samples...
Hi Roberto, Francesco and other.....
I quoted MrDuck, but not to replay only to him
I'm in agreement with you. But, please, must be manageable and it must not include any function other than error handling.
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
I quoted MrDuck, but not to replay only to him
I'm sorry I don't understand what is "any compatibility switch". Do you think about "-DHMG3" or about "-w3, -es2, -strip"?mrduck wrote:1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
Do you think about Xbase command style. With mixed OOP/Xbase can be, but... with OOP there isn't reason.mrduck wrote:2. The windows variables should be declared using MEMVAR.
Code: Select all
CLASS MyClass
DATA MyWindow INIT NIL
METHOD New(...) CLASS MyClass
::MyWindow := MAINWINDOW():New(...)
etc...
I'm in agreement with you: for allmrduck wrote:3. We should use the ':' operator (instead of '.').
.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.
Total in agreement. It's similar to "alternate syntax" and very manageable.mrduck wrote:5. As mentioned in the intro, only the new definition style (one property per line) should be used.
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
www.L3W.it
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: About HMG.4 Samples...
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.l3whmg wrote:I'm sorry I don't understand what is "any compatibility switch". Do you think about "-DHMG3" or about "-w3, -es2, -strip"?mrduck wrote:1. We must be able to build them without using any compatibility switch or changes to buildapp.bat.
Do you think about Xbase command style. With mixed OOP/Xbase can be, but... with OOP there isn't reason.mrduck wrote:2. The windows variables should be declared using MEMVAR.
[/code]
I'm talking about the forst case, of course.
I'm in agreement with you: for allmrduck wrote:3. We should use the ':' operator (instead of '.').
.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.
Total in agreement. It's similar to "alternate syntax" and very manageable.mrduck wrote:5. As mentioned in the intro, only the new definition style (one property per line) should be used.
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)
Roberto
(Veritas Filia Temporis)
Re: About HMG.4 Samples...
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
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
www.L3W.it
Re: About HMG.4 Samples...
Hi Roberto,
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.
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:
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:
is semioop or xBase ? I think it is both....
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 )))
here I need to explain a bit.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.
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\>() ;;
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
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
Code: Select all
Test.setFocus
... message is too long... I stop here )))
Re: About HMG.4 Samples...
Not deprecated, let's say "best effort"...mrduck wrote: IF (ipotesis) OOP is official, semioop supported and xbase syntax deprecated
"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
- 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 ?
- Roberto Lopez
- HMG Founder
- Posts: 4004
- Joined: Wed Jul 30, 2008 6:43 pm
Re: [EDITED] About HMG.4 Samples...
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:
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.
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
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)
Roberto
(Veritas Filia Temporis)