Menu
▾
▴
hwgui-developers
|
From: Alexander S.K. <al...@be...> - 2013-01-10 12:38:23
|
Leonardo, in December I started to do some restructuring of Hwgui. The reasons and directions of changes was discussed here. The incompatibilities you write about are caused by the following: three ( for now ) classes - HStatic, HButton and HGroup are replaced by more simple and fast code with limited functionality, sufficient for most applications, and new classes was created - HStaticEx, HButtonX and HGroupEx, which are in fact the same as HStatic, HButton and HGroup before the changes. New commands was introduced in guilib.ch - SAYEX, BUTTONX and GROUPEX for these classes. So the "lost" clauses are in these new commands. What is a most suitable way to provide compatibility is still an open question. For example, we can create a new .ch, where old SAY, BUTTON, GROUP commands will be related with new "ex" classes. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2013-01-10 13:07:37
|
> For example, we can
> create a new .ch, where old SAY, BUTTON, GROUP commands will be related
> with new "ex" classes.
Maybe, it is better to place in guilib.ch two SAY commands with
different syntax:
#xcommand @ <x>,<y> SAY [ <oSay> CAPTION ] <caption> ;
[ OF <oWnd> ] ;
[ ID <nId> ] ;
[ SIZE <width>, <height> ] ;
[ COLOR <color> ] ;
[ BACKCOLOR <bcolor> ] ;
[<lTransp: TRANSPARENT>] ;
[ ON INIT <bInit> ] ;
[ ON SIZE <bSize> ] ;
[ ON PAINT <bDraw> ] ;
[ ON CLICK <bClick> ] ;
[ ON DBLCLICK <bDblClick> ];
[[ON OTHER MESSAGES <bOther>][ON OTHERMESSAGES <bOther>]] ;
[ STYLE <nStyle> ] ;
[ FONT <oFont> ] ;
[ TOOLTIP <ctoolt> ] ;
=> ;
[<oSay> := ] HStaticEx():New(
<oWnd>,<nId>,<nStyle>,<x>,<y>,<width>, ;
<height>,<caption>,<oFont>,<bInit>,<bSize>,<bDraw>,<ctoolt>, ;
<color>,<bcolor>,<.lTransp.>,<bClick>,<bDblClick>,<bOther> );;
[ <oSay>:name := <(oSay)> ]
#xcommand @ <x>,<y> SAY [ <oSay> CAPTION ] <caption> ;
[ OF <oWnd> ] ;
[ ID <nId> ] ;
[ SIZE <width>, <height> ] ;
[ COLOR <color> ] ;
[ BACKCOLOR <bcolor> ] ;
[<lTransp: TRANSPARENT>] ;
[ ON INIT <bInit> ] ;
[ ON SIZE <bSize> ] ;
[ ON PAINT <bDraw> ] ;
[ STYLE <nStyle> ] ;
[ FONT <oFont> ] ;
[ TOOLTIP <ctoolt> ] ;
=> ;
[<oSay> := ] HStatic():New(
<oWnd>,<nId>,<nStyle>,<x>,<y>,<width>, ;
<height>,<caption>,<oFont>,<bInit>,<bSize>,<bDraw>,<ctoolt>, ;
<color>,<bcolor>,<.lTransp.> );;
[ <oSay>:name := <(oSay)> ]
in this case the
@ 20,10 SAY cText SIZE 260, 22
will be preprocessed to
HStatic():New(,,,20,10,260, 22,cText,,,,,,,,.F. );
and the
@ 20,10 SAY cText SIZE 260, 22 ON DBLCLICK {||MsgInfo("!")}
to:
HStaticEx():New(,,,20,10,260, 22,cText,,,,,,,,.F.,,{||MsgInfo("!")}, );
Any opinions are highly appreciated.
Regards, Alexander.
|
|
From: oleksa <m.o...@uk...> - 2013-01-10 17:57:16
|
Hi!
If we decide to keep both in the same file, i suggest the next syntax
#xcommand @ <x>,<y> SAY EXTENDED [ <oSay> CAPTION ] <caption> ;
[ OF <oWnd> ] ;
...
=> ;
[<oSay> := ] HStaticEx():New(
<oWnd>,<nId>,<nStyle>,<x>,<y>,<width>, ;
<height>,<caption>,<oFont>,<bInit>,<bSize>,<bDraw>,<ctoolt>, ;
<color>,<bcolor>,<.lTransp.>,<bClick>,<bDblClick>,<bOther> );;
[ <oSay>:name := <(oSay)> ]
because the minimum we need is
@ x,y say csay1 size 100,24
and in that case if the error is happened, the situation is not clear where, in hstatic or hstaticex.
And how it will look in the documentation:
... if you use the clause [ ON DBLCLICK <bDblClick> ] then works a hstaticex if no, then hstatic ...
again not clear for newbie.
In other case we will include the extended command even if we are not use them.
Regards,
Alexey Myronenko
|
|
From: Alexander S.K. <al...@be...> - 2013-01-14 12:30:44
|
oleksa ?????:
> Hi!
>
> If we decide to keep both in the same file, i suggest the next syntax
>
> #xcommand @ <x>,<y> SAY EXTENDED [ <oSay> CAPTION ] <caption> ;
> [ OF <oWnd> ] ;
> ...
> => ;
> [<oSay> := ] HStaticEx():New(
> <oWnd>,<nId>,<nStyle>,<x>,<y>,<width>, ;
> <height>,<caption>,<oFont>,<bInit>,<bSize>,<bDraw>,<ctoolt>, ;
> <color>,<bcolor>,<.lTransp.>,<bClick>,<bDblClick>,<bOther> );;
> [ <oSay>:name := <(oSay)> ]
>
I like the 'SAY EXTENDED' as a replacement for 'SAYEX', but this
doesn't solve the compatibility problem. For now people will get compile
errors, if they use those additional clauses with SAY and they must
change all such commands to SAYEx or SAY EXTENDED, or use other
guilib.ch ( the same about GROUP, BUTTON, and, later, some others ). The
solution, which I suggested, allows to get rid of errors and it is quite
logical, I think: if someone use extra functionality, writing additional
clauses in SAY command, "ex" class is called, if no - basic. IF a
programmer want to use "ex" class in all cases, with any clauses, he
should write SAY EXTENDED (or SAY EXT), we may provide this:
#xcommand @ <x>,<y> SAY [ <lExt: EXTENDED,EXT> ] [ <oSay> CAPTION ]
<caption> ;
[ OF <oWnd> ] ;
...
[ ON DBLCLICK <bDblClick> ];
...
=> ;
[<oSay> := ] HStaticEx():New(
...
#xcommand @ <x>,<y> SAY [ <oSay> CAPTION ] <caption> ;
[ OF <oWnd> ] ;
...
=> ;
[<oSay> := ] HStatic():New(
...
Regards, Alexander
|
|
From: Alexander S.K. <al...@be...> - 2013-01-15 09:28:25
|
So, if nobody objects, I'll change declarations of SAYEX, BUTTONX,
GROUPEX commands in guilib.ch in following way:
#xcommand @ <x>,<y> SAY [ <lExt: EXTENDED,EXT> ] [ <oSay> CAPTION ]
<caption> ;
[ OF <oWnd> ] ;
...
[ ON DBLCLICK <bDblClick> ];
...
=> ;
[<oSay> := ] HStaticEx():New(
...
After this change the following lines:
@ 20,10 SAY cText SIZE 260, 22
@ 20,10 SAY cText SIZE 260, 22 ON DBLCLICK {||MsgInfo("!")}
@ 20,10 SAY EXT cText SIZE 260, 22
will be preprocessed into:
HStatic():New(,,,20,10,260, 22,cText,,,,,,,,.F. );
HStaticEx():New(,,,20,10,260, 22,cText,,,,,,,,.F.,,{||MsgInfo("!")}, );
HStaticEx():New(,,,20,10,260, 22,cText,,,,,,,,.F.,,, );
Thus, if we use additional clauses, which demands functionality of "ex"
classes, the command will be preprocessed to a call of "ex" class (
HStaticEx, etc. ). If we don't use them, the command will be
preprocessed into a call of a base class ( HStatic, etc. ). I someone
want to use "ex" class independently of the comand clauses, he should
use "EXTENDED" or "EXT" word ( SAY EXT, etc. ).
Regards, Alexander.
|
|
From: oleksa <m.o...@uk...> - 2013-01-15 09:43:55
|
Ok, do it!
Regards,
Alexey Myronenko
--- Оригінальне повідомлення ---
Від кого: "Alexander S.Kresin" <al...@be...>
Кому: hwg...@li...
Дата: 15 січня 2013, 11:28:29
Тема: Re: [Hwgui-developers] Some incompatibilities with previous versions
> So, if nobody objects, I'll change declarations of SAYEX, BUTTONX,
> GROUPEX commands in guilib.ch in following way:
>
> #xcommand @ <x>,<y> SAY [ <lExt: EXTENDED,EXT> ] [ <oSay> CAPTION ]
> <caption> ;
> [ OF <oWnd> ] ;
> ...
> [ ON DBLCLICK <bDblClick> ];
> ...
> => ;
> [<oSay> := ] HStaticEx():New(
> ...
>
> After this change the following lines:
>
> @ 20,10 SAY cText SIZE 260, 22
> @ 20,10 SAY cText SIZE 260, 22 ON DBLCLICK {||MsgInfo("!")}
> @ 20,10 SAY EXT cText SIZE 260, 22
>
> will be preprocessed into:
>
> HStatic():New(,,,20,10,260, 22,cText,,,,,,,,.F. );
> HStaticEx():New(,,,20,10,260, 22,cText,,,,,,,,.F.,,{||MsgInfo("!")}, );
> HStaticEx():New(,,,20,10,260, 22,cText,,,,,,,,.F.,,, );
>
> Thus, if we use additional clauses, which demands functionality of "ex"
> classes, the command will be preprocessed to a call of "ex" class (
> HStaticEx, etc. ). If we don't use them, the command will be
> preprocessed into a call of a base class ( HStatic, etc. ). I someone
> want to use "ex" class independently of the comand clauses, he should
> use "EXTENDED" or "EXT" word ( SAY EXT, etc. ).
>
> Regards, Alexander.
>
> ------------------------------------------------------------------------------
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
> _______________________________________________
> Hwgui-developers mailing list
> Hwg...@li...
> https://lists.sourceforge.net/lists/listinfo/hwgui-developers
|
|
From: Alex S. <ss...@mw...> - 2013-01-10 14:47:21
|
On 2013/01/10 02:37 PM, Alexander S.Kresin wrote:
> clauses are in these new commands. What is a most suitable way to
> provide compatibility is still an open question. For example, we can
> create a new .ch, where old SAY, BUTTON, GROUP commands will be related
> with new "ex" classes.
To allow using different classes with a command I did this (see CLASS
clause):
#xcommand @ <x>,<y> GET [ <oEdit> VAR ] <vari> ;
[ OF <oWnd> ] ;
[ ID <nId> ] ;
[ SIZE <width>, <height> ] ;
[ COLOR <color> ] ;
[ BACKCOLOR <bcolor> ] ;
[ PICTURE <cPicture> ] ;
[ WHEN <bGfocus> ] ;
[ VALID <bLfocus> ] ;
[<lPassword: PASSWORD>] ;
[ MAXLENGTH <nMaxLength> ] ;
[ STYLE <nStyle> ] ;
[<lnoborder: NOBORDER>] ;
[ FONT <oFont> ] ;
[ ON INIT <bInit> ] ;
[ TOOLTIP <ctoolt> ] ;
[ ON KEYDOWN <bKeyDown> ];
[ ON CHANGE <bChange> ] ;
[ ON CHANGE <bChange> ] ;
[ <class: CLASS> <classname> ] ;
=> ;
[<oEdit> := ] __IIF(<.class.>, <classname>, HEdit)():New(
<oWnd>,<nId>,<vari>, ;
{|v|Iif(v==Nil,<vari>,<vari>:=v)}, ;
<nStyle>,<x>,<y>,<width>,<height>,<oFont>,<bInit>,,, ;
<bGfocus>,<bLfocus>,<ctoolt>,<color>,<bcolor>,<cPicture>,;
<.lnoborder.>,<nMaxLength>,<.lPassword.>,<bKeyDown>, <bChange>)
It doesn't really help in your situation now but I always wished it was
implemented for all relevant commands because then you are free to
inherit from the HWGUI classes but you don't have to rewrite the command
to use your new class. In this way the EX versions need not have created
new commands unless they had new clauses.
--
Regards
Alex
|
|
From: Alex S. <ss...@mw...> - 2013-01-16 10:24:26
|
On 2013/01/15 03:04 PM, Alexander S.Kresin wrote:
> It looks interesting for me. We could add this clause to all our
> commands, but I can't make it to work - it gives errors while
> compiling. And what is the __IIF ?
Sorry, I did not give you the complete code, here is a minimal example
with all that is required:
#xtranslate __IIF(.T., [<true>], [<false>]) => <true>
#xtranslate __IIF(.F., [<true>], [<false>]) => <false>
#xcommand JOINSTR <a>, <b> [ <fcn: FCN> <fcnname> ] => ;
__IIF(<.fcn.>, <fcnname>, Join)(<a>, <b>)
procedure main
JOINSTR "a", "b"
JOINSTR "a", "b" FCN MyJoin
return
procedure Join(a, b)
? a + b
procedure MyJoin(a, b)
? a + ", " + b
--
Regards
Alex
|
|
From: Alexander S.K. <al...@be...> - 2013-01-17 06:27:23
|
Alex Strickland writes: > > #xtranslate __IIF(.T., [<true>], [<false>]) => <true> > #xtranslate __IIF(.F., [<true>], [<false>]) => <false> > > #xcommand JOINSTR <a>, <b> [ <fcn: FCN> <fcnname> ] => ; > __IIF(<.fcn.>, <fcnname>, Join)(<a>, <b>) > > > procedure main > > JOINSTR "a", "b" > > JOINSTR "a", "b" FCN MyJoin > > return > > procedure Join(a, b) > > ? a + b > > procedure MyJoin(a, b) > > ? a + ", " + b > Great! I never thought that this is possible. Could you provide guilib.ch with appropriate changes ? Regards, Alexander. |
|
From: Alex S. <ss...@mw...> - 2013-01-17 08:03:29
|
On 2013/01/17 08:26 AM, Alexander S.Kresin wrote: > Great! I never thought that this is possible. Could you provide > guilib.ch with appropriate changes ? This idea is taken from Clip4Win written by John Skelton. He took some interest in Harbour in the early days, I really wish he had stuck around, it was an excellent library. Yes, I'll do it. -- Regards Alex |
|
From: Alex S. <ss...@mw...> - 2013-01-15 11:46:54
|
On 2013/01/10 04:47 PM, Alex Strickland wrote: > It doesn't really help in your situation now but I always wished it > was implemented for all relevant commands because then you are free to > inherit from the HWGUI classes but you don't have to rewrite the > command to use your new class. In this way the EX versions need not > have created new commands unless they had new clauses. No comments here ..., is it a bad idea? -- Regards Alex |
|
From: Alexander S.K. <al...@be...> - 2013-01-15 13:04:51
|
Alex Strickland writes: >> It doesn't really help in your situation now It is a key sentence :). It doesn't help in compatibility problem - people still need to change the syntax of appropriate commands. >> but I always wished it >> was implemented for all relevant commands because then you are free to >> inherit from the HWGUI classes but you don't have to rewrite the >> command to use your new class. In this way the EX versions need not >> have created new commands unless they had new clauses. In our case all these EX versions have new clauses. > No comments here ..., is it a bad idea? > It looks interesting for me. We could add this clause to all our commands, but I can't make it to work - it gives errors while compiling. And what is the __IIF ? Regards, Alexander. |
Thanks for helping keep SourceForge clean.
X