Menu
▾
▴
hwgui-developers — Discussing of HwGUI development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(64) |
Apr
(70) |
May
(54) |
Jun
(57) |
Jul
(34) |
Aug
(19) |
Sep
(28) |
Oct
(48) |
Nov
(42) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(50) |
Feb
(19) |
Mar
(10) |
Apr
(5) |
May
(1) |
Jun
(14) |
Jul
(23) |
Aug
(6) |
Sep
(118) |
Oct
(110) |
Nov
(36) |
Dec
(6) |
| 2006 |
Jan
(19) |
Feb
(7) |
Mar
(4) |
Apr
(32) |
May
(6) |
Jun
(14) |
Jul
(42) |
Aug
(38) |
Sep
(88) |
Oct
(21) |
Nov
(40) |
Dec
(37) |
| 2007 |
Jan
(31) |
Feb
(20) |
Mar
(26) |
Apr
(38) |
May
(4) |
Jun
(3) |
Jul
(3) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(25) |
Dec
(9) |
| 2008 |
Jan
(7) |
Feb
(10) |
Mar
(16) |
Apr
(10) |
May
(25) |
Jun
(16) |
Jul
(27) |
Aug
(8) |
Sep
(20) |
Oct
(54) |
Nov
(11) |
Dec
(14) |
| 2009 |
Jan
(28) |
Feb
(22) |
Mar
(13) |
Apr
(70) |
May
(25) |
Jun
(23) |
Jul
(12) |
Aug
(18) |
Sep
(7) |
Oct
(4) |
Nov
(8) |
Dec
(36) |
| 2010 |
Jan
(58) |
Feb
(66) |
Mar
(3) |
Apr
(16) |
May
(9) |
Jun
(10) |
Jul
(6) |
Aug
(8) |
Sep
(17) |
Oct
(15) |
Nov
(12) |
Dec
(27) |
| 2011 |
Jan
(3) |
Feb
(17) |
Mar
(5) |
Apr
(12) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
(56) |
Oct
(24) |
Nov
(8) |
Dec
(32) |
| 2012 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(29) |
Aug
(3) |
Sep
(17) |
Oct
(60) |
Nov
(17) |
Dec
(52) |
| 2013 |
Jan
(22) |
Feb
(35) |
Mar
(31) |
Apr
(5) |
May
(16) |
Jun
(108) |
Jul
(57) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
(3) |
Dec
(13) |
| 2014 |
Jan
(39) |
Feb
(15) |
Mar
|
Apr
(31) |
May
|
Jun
(9) |
Jul
(16) |
Aug
(1) |
Sep
(8) |
Oct
(51) |
Nov
(5) |
Dec
(119) |
| 2015 |
Jan
(78) |
Feb
(47) |
Mar
(25) |
Apr
(32) |
May
(34) |
Jun
(42) |
Jul
(62) |
Aug
(10) |
Sep
(11) |
Oct
(5) |
Nov
(13) |
Dec
(24) |
| 2016 |
Jan
(12) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(12) |
Jul
(5) |
Aug
(32) |
Sep
(36) |
Oct
(34) |
Nov
(3) |
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(5) |
Jul
(6) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(26) |
Sep
(24) |
Oct
(2) |
Nov
(6) |
Dec
(26) |
| 2019 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
|
From: Alex <al...@be...> - 2012-12-26 15:52:45
|
> the purpose is they have the same behavior of objects that are inherited > from hcwindows. Having Methodo Init they can be initialized in the > activation form. > Sorry, I understood nothing. The HObject is a base class in HwGUI, so all its data and methods are inherited by all other classes. Why they are needed in controls or in windows ? Why should we initialize them in activation form ? Is there any sample, which shows, how to use them ? Regards, Alexander. ________________________________________________ |
|
From: Basso, L. F. <lf...@vi...> - 2012-12-26 15:19:18
|
Hi the purpose is they have the same behavior of objects that are inherited from hcwindows. Having Methodo Init they can be initialized in the activation form. Regards; Basso -----Mensagem Original----- From: Alex Sent: Wednesday, December 26, 2012 1:12 PM To: hwg...@li... Subject: [Hwgui-developers] HObject data and methods Hi, could anybody explain me, what is a purpose of HObject:aObjects and appropriate methods ? Are they really needed ? Regards, Alexander. ________________________________________________ ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Hwgui-developers mailing list Hwg...@li... https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Alex <al...@be...> - 2012-12-26 15:12:27
|
Hi, could anybody explain me, what is a purpose of HObject:aObjects and appropriate methods ? Are they really needed ? Regards, Alexander. ________________________________________________ |
|
From: Alex <al...@be...> - 2012-12-26 15:09:17
|
Fixed. > Hi! > > > sourcehcontrol.prg(1121) Warning W0001 Method <Activate> not declared or declaration mismatch in class <HGroup> > > No code generated. > hbmk2: Error: Running Harbour compiler (embedded). 1 > > Regards, > Alexey Myronenko > > ________________________________________________ |
|
From: oleksa <m.o...@uk...> - 2012-12-26 14:48:06
|
Hi! source\hcontrol.prg(1121) Warning W0001 Method <Activate> not declared or declaration mismatch in class <HGroup> No code generated. hbmk2: Error: Running Harbour compiler (embedded). 1 Regards, Alexey Myronenko |
|
From: Alexander S.K. <al...@be...> - 2012-12-26 10:03:13
|
Hi, I've uploaded some changes, related to splitting controls to base and "ex" for the simplest HGroup class just to show what I have in mind and to test how it will work. Now there is a base simple HGroup in hcontrol.prg ( I took it from an old version ) and HGroupEx in hctrlex.prg, which was HGroup in current version. And, secondly, I added a GROUPBOXEX command in guilib.ch for HGroupEx. If it is inconvenient for you ( because, if you need the extended functionality of the HGroupex, you'll need to change the command GROUPBOX to GROUPBOXEX ) we can rename the HGroup to, for example, HGroupBase, and HGroupEx back to HGroup and rename the commands, too. I ask this question before appropriate changes in HStatic, HButton to find a solution, most suitable for you all. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2012-12-26 08:58:50
|
Hi, first of all, my sincere congratulations with the Cristmas to all who celebrate it. Here, in Russia, we will celebrate Cristmas on Janyary, 7 - we use Julian calendar for religious feasts. So, I'm at work in these days and begin some changes in HwGUI accordingly to the ideas that I expressed earlier. I want to add new point to the plan: adding the "hwg" prefix to all functions, which aren't prefixed yet. The first victim :) was functions from the wprint.c. I've added a header file hwgcompat.ch with necessary xtranslate's, so anyone, who don't want to change the function calls in his sources, may include it. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2012-12-21 10:35:42
|
oleksa writes: > Hi! > > Tested with hwgui\utils\designer\samples\example.prg (hwgui ver * $Id: Changelog 1963 2012-12-14 07:40:24Z alkresin $) > Ownerbutton with set flat to .t. stays selected after click on it, can someone confirm that? > Yes, the same here. Moreover, they works chaotically... Regards, Alexander. |
|
From: oleksa <m.o...@uk...> - 2012-12-19 10:43:22
|
Hi! Tested with hwgui\utils\designer\samples\example.prg (hwgui ver * $Id: Changelog 1963 2012-12-14 07:40:24Z alkresin $) Ownerbutton with set flat to .t. stays selected after click on it, can someone confirm that? Regards, Alexey Myronenko |
|
From: Alexander S.K. <al...@be...> - 2012-12-14 09:05:55
|
Basso, Luis Fernando writes: > Hi > I think the current version of Windows HWGUI is very productive and > optimized and most of the new code was added simply to add new features and > fix events. In my opinion, and, I'm not alone, HwGUI becomes huge, bad structured and bad readable. I am far from being able to accuse anyone, there is my fault, too. I just want to do some work on restructuring the library code to make it compact, light weight and clear, if I could. The main directions as I see it, are the following: 1) clean basic controls, moving extra features to inherited controls ( HStatic => HStaticEx ); 2) get rid off redundant variables and methods without loss of appropriate functionality; 3) fixing some violations of a logic of classes construction ( as the occasion, when HCustomWIndow code calls vars from child classes ); 4) moving some rarely used stuff, which have no relation to the purposes of a library to contrib directory ( for example, the richtext.prg, saymoney.prg ). Maybe, I missed something - I'll be glad to here any advices. This isn't a two days work, but step by step we can do it. > "To be more concrete, I Consider The Following methods of > HCustomWindow the redundant: ResetScrollbars (), SetupScrollbars (), > RedefineScrollbars () - They Do not needed because for most controls, " > These methods are for scrolling windows of objects in containers as class > HPanel. Taking the class hcwindow would have to be repeated in other classes > that were using it, or convert them to functions. Maybe, to have them as functions, is better than to have them in all controls, such as static or edit, where they are redundant. It is possible to declare those functions as EXTERN methods in a classes where they are needed. Or we may create a class as HContainer and make such classes as HPanel inherited from both HControl and HContainer. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2012-12-13 13:07:20
|
Basso, Luis Fernando writes: > WindowState property HWindow class stores the state of the window, if > Minimized, Maximized, and is in funcition OnSize the WM_SIZE message is > triggered > ... Thanks for the clarification. But I wrote about other thing. The code, which use Hwindow vars, should be placed in HWindow class prg, or in other place, but not in hcwindow.prg, which is parent of hwindow. HCustomWindow must know nothing about it childs - for proper and clear code. Child class can use vars of parent, but not vice versa. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2012-12-13 12:35:06
|
Alex Strickland writes:
> On 2012/12/13 01:34 PM, Alexander S.Kresin wrote:
>> Yet another typical things, which must be corrected:
>>
> I was not able to understand why this kind of code was necessary:
>
> ::oparent:lSuspendMsgsHandling := .T.
As I see from the Changelog, it was introduced by Luis Fernando Basso:
2008-09-01 21:00 UTC+0100 Maurizio la Cecilia <m.l...@gm...>
This commit contains all the changes made by Luis Fernando Basso
...
* added lSuspendMsgsHandling property allowing centralized
control of event handling
It would be nice if Luis ( can I call you that ? ) tell us in details
about this.
>
> It seems to be in every class.
>
> This kind of code in hbrowse.prg is horrible:
>
> ::internal[ 1 ] := SetBit( ::internal[ 1 ], 1, 0 )
This is my old code :) and, agree, it isn't good.
>
> and this in hedit.prg :
>
> ELSEIF wParam == 39 // KeyRight
> ::lFocu := .F.
> IF ! IsCtrlShift()
> ::lFirst := .F.
> RETURN ::KeyRight()
> ENDIF
> ELSEIF wParam == 37 // KeyLeft
>
> Some people seem to think #define is evil.
>
Suggest your version :)
Regards, Alexander.
|
|
From: Basso, L. F. <lf...@vi...> - 2012-12-13 12:15:02
|
CORRECTING
This code is necessary because it allows the recursive effect in the
event SETFOUCS, LOSTFOCUS etc.
-----Mensagem Original-----
From: Basso, Luis Fernando
Sent: Thursday, December 13, 2012 10:09 AM
To: hwg...@li...
Subject: Re: [Hwgui-developers] HwGUI - the continuation
::oparent:lSuspendMsgsHandling := .T.
This code is not necessary because it allows the recursive effect in the
event SETFOUCS, LOSTFOCUS etc.
example
In the LostFocus event if you put a simple MSGINFO you will have the effect
that triggers the recursive MSGINFO several times.
-----Mensagem Original-----
From: Alex Strickland
Sent: Thursday, December 13, 2012 9:56 AM
To: hwg...@li...
Subject: Re: [Hwgui-developers] HwGUI - the continuation
On 2012/12/13 01:34 PM, Alexander S.Kresin wrote:
> Yet another typical things, which must be corrected:
>
I was not able to understand why this kind of code was necessary:
::oparent:lSuspendMsgsHandling := .T.
It seems to be in every class.
This kind of code in hbrowse.prg is horrible:
::internal[ 1 ] := SetBit( ::internal[ 1 ], 1, 0 )
and this in hedit.prg :
ELSEIF wParam == 39 // KeyRight
::lFocu := .F.
IF ! IsCtrlShift()
::lFirst := .F.
RETURN ::KeyRight()
ENDIF
ELSEIF wParam == 37 // KeyLeft
Some people seem to think #define is evil.
Nice to see you back.
I think you undertake quite a task!
--
Regards
Alex
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Hwgui-developers mailing list
Hwg...@li...
https://lists.sourceforge.net/lists/listinfo/hwgui-developers
|
|
From: Basso, L. F. <lf...@vi...> - 2012-12-13 12:10:08
|
::oparent:lSuspendMsgsHandling := .T.
This code is not necessary because it allows the recursive effect in the
event SETFOUCS, LOSTFOCUS etc.
example
In the LostFocus event if you put a simple MSGINFO you will have the effect
that triggers the recursive MSGINFO several times.
-----Mensagem Original-----
From: Alex Strickland
Sent: Thursday, December 13, 2012 9:56 AM
To: hwg...@li...
Subject: Re: [Hwgui-developers] HwGUI - the continuation
On 2012/12/13 01:34 PM, Alexander S.Kresin wrote:
> Yet another typical things, which must be corrected:
>
I was not able to understand why this kind of code was necessary:
::oparent:lSuspendMsgsHandling := .T.
It seems to be in every class.
This kind of code in hbrowse.prg is horrible:
::internal[ 1 ] := SetBit( ::internal[ 1 ], 1, 0 )
and this in hedit.prg :
ELSEIF wParam == 39 // KeyRight
::lFocu := .F.
IF ! IsCtrlShift()
::lFirst := .F.
RETURN ::KeyRight()
ENDIF
ELSEIF wParam == 37 // KeyLeft
Some people seem to think #define is evil.
Nice to see you back.
I think you undertake quite a task!
--
Regards
Alex
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Hwgui-developers mailing list
Hwg...@li...
https://lists.sourceforge.net/lists/listinfo/hwgui-developers
|
|
From: Basso, L. F. <lf...@vi...> - 2012-12-13 12:04:20
|
Hi WindowState property HWindow class stores the state of the window, if Minimized, Maximized, and is in funcition OnSize the WM_SIZE message is triggered #define SW_HIDE 0 #define SW_SHOWNORMAL 1 #define SW_NORMAL 1 #define SW_SHOWMINIMIZED 2 #define SW_SHOWMAXIMIZED 3 #define SW_MAXIMIZE 3 #define SW_SHOWNOACTIVATE 4 Regards Luis Fernando -----Mensagem Original----- From: Alexander S.Kresin Sent: Thursday, December 13, 2012 9:34 AM To: hwg...@li... Subject: [Hwgui-developers] HwGUI - the continuation Yet another typical things, which must be corrected: 1) sometimes the developer creates a class variable while there is already the one, which is intended for the same purposes. For example, the oWndParent in HMDIChildWindow, seems, does the same, what could do the oParent, inherited from HCustomWindow. Maybe, I missed something in this particular occasion, but, as far as I remember, this isn't the only occasion; BTW, adding a new class variable/method, the developer should leave a note about this in the Changelog for further investigation. 2) the situation, when the code of a parent class uses vars/methods of a child class. For example, the onSize static function in hcwindow.prg, which realizes the functionality of HCustomWindow class, uses the WindowState variable of a child HWindow class. Regards, Alexander. ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Hwgui-developers mailing list Hwg...@li... https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Basso, L. F. <lf...@vi...> - 2012-12-13 11:57:22
|
Hi
At no time changes were made to the targeted DESIGNER or IDE. All implementations were to give more strength and control to the developer.
All lines of code done so with the intention of further optimization and elegance.
Regards
Luis Fernando
From: Maurizio la Cecilia
Sent: Thursday, December 13, 2012 8:55 AM
To: Alex Kresin
Cc: Hwgui-developers
Subject: Re: [Hwgui-developers] HwGUI development
Hi Alexander,
I fully agree with your opinions.
I stopped my hwgui development just because his growth made this lib less elegant and effective than the original implementation.
I already wrote about this question many times, but honestly I never had time and strength to limit the impressive blowing up of the changes and control the accordance to the first plot.
Most of the changes, I repeat myself, was made having as principal target the xdesigner needs and then the library enhancement.
So mine it's a great yes to redraw the hwgui framework optimizing it to a more effective structure and usage also when, as I was doing, the developer don't use the designer.
Thanks for your new interest and welcome back.
BR
Maurizio
Il giorno 13/dic/2012 10:47, "Alexander S.Kresin" <al...@be...> ha scritto:
Hi All,
for a long time I didn't follow the HwGUI development. For my projects
I still use an old version, which is about 4 -5 years old. Sometimes,
quite rarely, I did necessary changes and uploaded them here. I didn't
use the renewed HwGUI from the SF repository because of a big number of
changes, for which I hadn't time and energy to review and to check. From
time to time I reviewed the new code partially and returned to my old
version because I found there many things, which I don't like.
Recently I was asked to review the Designer, because it has serious
problems. I've build it with a latest HwGUI code and Harbour 3.2 and
really found some:
1) incorrect appearance of non-English characters in some places - this
resolves very easy by setting appropriate codepage;
2) object inspector - the selected items remains coloured as selected al
the time - I don't know why yet, probably this goes from HBrowse;
3) when I try to open my report forms, the designer simply hangs.
I plan to investigate this problems deeper, but before I need to deal
with the current HwGUI code. As I wrote above, there are things, which I
don't like and which prevent me to upgrade to the newest version. There
is a lot of additions, I believe that they are useful and really makes
HwGUI better. The problem is with structure.
From the beginning I tried to make HwGUI compact and fast. My code
wasn't ideal ( now it is a bit better :), and I hope it will better in
future - we all are learning till the end of the life ) and there was
fragments which I don't like. But now, from the point of a class
structure, the things became even worse. I believe, that classes,
especially basic classes, which have many objects, should have minimum
of variables and methods - only that, which are really necessary. When
HCustomWindow has some redundant variables and methods, the HControl,
which inherits from it, adds new redundant, the final, for example, most
frequently encountered HStatic has a number of redundant stuff. We have
a lot of HStatic, HEdit, etc. objects in a form, each of them contains a
lot of rubbish, which makes their response time bigger, though they
never use it.
Why the response time become bigger ? Each control gets a lot of
Windows messages, each message is handled in HwGUI code to find
appropriate method and execute it. The more methods and vars has the
object, the more time is needed to find necessary one.
To be more concrete, I consider the following methods of
HCustomWindow as redundant: ResetScrollbars(), SetupScrollbars(),
RedefineScrollbars() - because they don't needed for most controls,
which inherits from HCustomWindow; GetParentForm() - from my point, it
is better to write as a function; Hcontrol: FontBold(), FontItalic(),
FontUnderline() - I don't see any reson why they should be separate
methods. These are only examples, just to clarify my point. There is
more stuff which, in my opinion, should be cleared.
The second important thing is adding of new features to controls. Look
at HBrowse or HEdit - they became so big that it is very difficult to
review and understand their work. I believe that most of these new
features are useful, but why we put them into the same class ? We
absolutely forget about such thing as Inheritance ( the only good
exception is the HButtonEx by Luiz - but, IMO, it should be placed in
separate file ). I prefer to have simple control classes with basic
features, which are demanded in most cases and inherited from them,
maybe multiply, "ex" classes - for to keep basic set clean, fast and
readable.
So, I suggest to rewrite some parts of HwGUI in accordance with these
thoughts and I'd like to hear your opinions.
Regards, Alexander.
P.S. Uff... I hate to write such a long texts, especially on English :)
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p..sf.net/sfu/logmein_12329d2d
_______________________________________________
Hwgui-developers mailing list
Hwg...@li...
https://lists.sourceforge.net/lists/listinfo/hwgui-developers
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
--------------------------------------------------------------------------------
_______________________________________________
Hwgui-developers mailing list
Hwg...@li...
https://lists.sourceforge.net/lists/listinfo/hwgui-developers
|
|
From: Alex S. <ss...@mw...> - 2012-12-13 11:56:28
|
On 2012/12/13 01:34 PM, Alexander S.Kresin wrote:
> Yet another typical things, which must be corrected:
>
I was not able to understand why this kind of code was necessary:
::oparent:lSuspendMsgsHandling := .T.
It seems to be in every class.
This kind of code in hbrowse.prg is horrible:
::internal[ 1 ] := SetBit( ::internal[ 1 ], 1, 0 )
and this in hedit.prg :
ELSEIF wParam == 39 // KeyRight
::lFocu := .F.
IF ! IsCtrlShift()
::lFirst := .F.
RETURN ::KeyRight()
ENDIF
ELSEIF wParam == 37 // KeyLeft
Some people seem to think #define is evil.
Nice to see you back.
I think you undertake quite a task!
--
Regards
Alex
|
|
From: Basso, L. F. <lf...@vi...> - 2012-12-13 11:49:56
|
Hi I think the current version of Windows HWGUI is very productive and optimized and most of the new code was added simply to add new features and fix events. "To be more concrete, I Consider The Following methods of HCustomWindow the redundant: ResetScrollbars (), SetupScrollbars (), RedefineScrollbars () - They Do not needed because for most controls, " These methods are for scrolling windows of objects in containers as class HPanel. Taking the class hcwindow would have to be repeated in other classes that were using it, or convert them to functions. He was tempted to standardize many properties such as CAPTION AND VALUE property that are used to assign values to controls. We added several methods that facilitate SETGET assign or compare values Regards Luis fernando -----Mensagem Original----- From: Andi Jahja Sent: Thursday, December 13, 2012 8:06 AM To: hwg...@li... Subject: Re: [Hwgui-developers] HwGUI development Hi Alexander: Well come back :-) I completely agree with you. Due to the reasons you elaborated, I stopped using HWGUI several years ago. I hope I can see HWGUI comes back to a LIGHT GUI for [x]Harbour. OFF TOPIC, your another project, LETODB, now has been so 'RUINNED' so that it cannot be compiled with xHarbour. I think this is VERY BAD. We need you assistance to revert this 'CRUEL' changes and makes it xHarbour-compatible again. Thank you very much. Andi On Thu, 13 Dec 2012 13:13:28 +0400 "Alexander S.Kresin" <al...@be...> wrote: > Hi All, > > for a long time I didn't follow the HwGUI development. For my projects > I still use an old version, which is about 4 -5 years old. Sometimes, > quite rarely, I did necessary changes and uploaded them here. I didn't > use the renewed HwGUI from the SF repository because of a big number of > changes, for which I hadn't time and energy to review and to check. From > time to time I reviewed the new code partially and returned to my old > version because I found there many things, which I don't like. > > Recently I was asked to review the Designer, because it has serious > problems. I've build it with a latest HwGUI code and Harbour 3.2 and > really found some: > 1) incorrect appearance of non-English characters in some places - this > resolves very easy by setting appropriate codepage; > 2) object inspector - the selected items remains coloured as selected al > the time - I don't know why yet, probably this goes from HBrowse; > 3) when I try to open my report forms, the designer simply hangs. > > I plan to investigate this problems deeper, but before I need to deal > with the current HwGUI code. As I wrote above, there are things, which I > don't like and which prevent me to upgrade to the newest version. There > is a lot of additions, I believe that they are useful and really makes > HwGUI better. The problem is with structure. > > From the beginning I tried to make HwGUI compact and fast. My code > wasn't ideal ( now it is a bit better :), and I hope it will better in > future - we all are learning till the end of the life ) and there was > fragments which I don't like. But now, from the point of a class > structure, the things became even worse. I believe, that classes, > especially basic classes, which have many objects, should have minimum > of variables and methods - only that, which are really necessary. When > HCustomWindow has some redundant variables and methods, the HControl, > which inherits from it, adds new redundant, the final, for example, most > frequently encountered HStatic has a number of redundant stuff. We have > a lot of HStatic, HEdit, etc. objects in a form, each of them contains a > lot of rubbish, which makes their response time bigger, though they > never use it. > Why the response time become bigger ? Each control gets a lot of > Windows messages, each message is handled in HwGUI code to find > appropriate method and execute it. The more methods and vars has the > object, the more time is needed to find necessary one. > To be more concrete, I consider the following methods of > HCustomWindow as redundant: ResetScrollbars(), SetupScrollbars(), > RedefineScrollbars() - because they don't needed for most controls, > which inherits from HCustomWindow; GetParentForm() - from my point, it > is better to write as a function; Hcontrol: FontBold(), FontItalic(), > FontUnderline() - I don't see any reson why they should be separate > methods. These are only examples, just to clarify my point. There is > more stuff which, in my opinion, should be cleared. > The second important thing is adding of new features to controls. Look > at HBrowse or HEdit - they became so big that it is very difficult to > review and understand their work. I believe that most of these new > features are useful, but why we put them into the same class ? We > absolutely forget about such thing as Inheritance ( the only good > exception is the HButtonEx by Luiz - but, IMO, it should be placed in > separate file ). I prefer to have simple control classes with basic > features, which are demanded in most cases and inherited from them, > maybe multiply, "ex" classes - for to keep basic set clean, fast and > readable. > > So, I suggest to rewrite some parts of HwGUI in accordance with these > thoughts and I'd like to hear your opinions. > > Regards, Alexander. > > P.S. Uff... I hate to write such a long texts, especially on English :) > > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Hwgui-developers mailing list Hwg...@li... https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: Alexander S.K. <al...@be...> - 2012-12-13 11:34:27
|
Yet another typical things, which must be corrected: 1) sometimes the developer creates a class variable while there is already the one, which is intended for the same purposes. For example, the oWndParent in HMDIChildWindow, seems, does the same, what could do the oParent, inherited from HCustomWindow. Maybe, I missed something in this particular occasion, but, as far as I remember, this isn't the only occasion; BTW, adding a new class variable/method, the developer should leave a note about this in the Changelog for further investigation. 2) the situation, when the code of a parent class uses vars/methods of a child class. For example, the onSize static function in hcwindow.prg, which realizes the functionality of HCustomWindow class, uses the WindowState variable of a child HWindow class. Regards, Alexander. |
|
From: Alexander S.K. <al...@be...> - 2012-12-13 11:16:13
|
Andi Jahja writes: > > OFF TOPIC, your another project, LETODB, now has been so 'RUINNED' so > that it cannot be compiled with xHarbour. I think this is VERY BAD. We > need you assistance to revert this 'CRUEL' changes and makes it > xHarbour-compatible again. > My intention always was to have HwGUI and Letodb working with both Harbour and xHarbour and, if possible, with different versions of them. As far as I know, Letodb is not in ruins, Pavel Tsarenko does a big job with it. If I'm right, the problem with xHarbour is in realization of mt mode. Letodb server works in mt mode now and the mt is realized with appropriate Harbour means, which, unfortunately, aren't compatible with xHarbour's. This is a real problem. But you can use letodb server, compiled on Harbour - maybe, ready binaries and client-side applications, compiled on xHarbour - as far as I know, rddleto can be compiled inder xHarbour. Regards, Alexander. |
|
From: Maurizio la C. <m.l...@gm...> - 2012-12-13 10:55:19
|
Hi Alexander, I fully agree with your opinions. I stopped my hwgui development just because his growth made this lib less elegant and effective than the original implementation. I already wrote about this question many times, but honestly I never had time and strength to limit the impressive blowing up of the changes and control the accordance to the first plot. Most of the changes, I repeat myself, was made having as principal target the xdesigner needs and then the library enhancement. So mine it's a great yes to redraw the hwgui framework optimizing it to a more effective structure and usage also when, as I was doing, the developer don't use the designer. Thanks for your new interest and welcome back. BR Maurizio Il giorno 13/dic/2012 10:47, "Alexander S.Kresin" <al...@be...> ha scritto: > Hi All, > > for a long time I didn't follow the HwGUI development. For my projects > I still use an old version, which is about 4 -5 years old. Sometimes, > quite rarely, I did necessary changes and uploaded them here. I didn't > use the renewed HwGUI from the SF repository because of a big number of > changes, for which I hadn't time and energy to review and to check. From > time to time I reviewed the new code partially and returned to my old > version because I found there many things, which I don't like. > > Recently I was asked to review the Designer, because it has serious > problems. I've build it with a latest HwGUI code and Harbour 3.2 and > really found some: > 1) incorrect appearance of non-English characters in some places - this > resolves very easy by setting appropriate codepage; > 2) object inspector - the selected items remains coloured as selected al > the time - I don't know why yet, probably this goes from HBrowse; > 3) when I try to open my report forms, the designer simply hangs. > > I plan to investigate this problems deeper, but before I need to deal > with the current HwGUI code. As I wrote above, there are things, which I > don't like and which prevent me to upgrade to the newest version. There > is a lot of additions, I believe that they are useful and really makes > HwGUI better. The problem is with structure. > > From the beginning I tried to make HwGUI compact and fast. My code > wasn't ideal ( now it is a bit better :), and I hope it will better in > future - we all are learning till the end of the life ) and there was > fragments which I don't like. But now, from the point of a class > structure, the things became even worse. I believe, that classes, > especially basic classes, which have many objects, should have minimum > of variables and methods - only that, which are really necessary. When > HCustomWindow has some redundant variables and methods, the HControl, > which inherits from it, adds new redundant, the final, for example, most > frequently encountered HStatic has a number of redundant stuff. We have > a lot of HStatic, HEdit, etc. objects in a form, each of them contains a > lot of rubbish, which makes their response time bigger, though they > never use it. > Why the response time become bigger ? Each control gets a lot of > Windows messages, each message is handled in HwGUI code to find > appropriate method and execute it. The more methods and vars has the > object, the more time is needed to find necessary one. > To be more concrete, I consider the following methods of > HCustomWindow as redundant: ResetScrollbars(), SetupScrollbars(), > RedefineScrollbars() - because they don't needed for most controls, > which inherits from HCustomWindow; GetParentForm() - from my point, it > is better to write as a function; Hcontrol: FontBold(), FontItalic(), > FontUnderline() - I don't see any reson why they should be separate > methods. These are only examples, just to clarify my point. There is > more stuff which, in my opinion, should be cleared. > The second important thing is adding of new features to controls. Look > at HBrowse or HEdit - they became so big that it is very difficult to > review and understand their work. I believe that most of these new > features are useful, but why we put them into the same class ? We > absolutely forget about such thing as Inheritance ( the only good > exception is the HButtonEx by Luiz - but, IMO, it should be placed in > separate file ). I prefer to have simple control classes with basic > features, which are demanded in most cases and inherited from them, > maybe multiply, "ex" classes - for to keep basic set clean, fast and > readable. > > So, I suggest to rewrite some parts of HwGUI in accordance with these > thoughts and I'd like to hear your opinions. > > Regards, Alexander. > > P.S. Uff... I hate to write such a long texts, especially on English :) > > > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Hwgui-developers mailing list > Hwg...@li... > https://lists.sourceforge.net/lists/listinfo/hwgui-developers > |
|
From: Andi J. <xha...@te...> - 2012-12-13 10:22:45
|
Hi Alexander: Well come back :-) I completely agree with you. Due to the reasons you elaborated, I stopped using HWGUI several years ago. I hope I can see HWGUI comes back to a LIGHT GUI for [x]Harbour. OFF TOPIC, your another project, LETODB, now has been so 'RUINNED' so that it cannot be compiled with xHarbour. I think this is VERY BAD. We need you assistance to revert this 'CRUEL' changes and makes it xHarbour-compatible again. Thank you very much. Andi On Thu, 13 Dec 2012 13:13:28 +0400 "Alexander S.Kresin" <al...@be...> wrote: > Hi All, > > for a long time I didn't follow the HwGUI development. For my projects > I still use an old version, which is about 4 -5 years old. Sometimes, > quite rarely, I did necessary changes and uploaded them here. I didn't > use the renewed HwGUI from the SF repository because of a big number of > changes, for which I hadn't time and energy to review and to check. From > time to time I reviewed the new code partially and returned to my old > version because I found there many things, which I don't like. > > Recently I was asked to review the Designer, because it has serious > problems. I've build it with a latest HwGUI code and Harbour 3.2 and > really found some: > 1) incorrect appearance of non-English characters in some places - this > resolves very easy by setting appropriate codepage; > 2) object inspector - the selected items remains coloured as selected al > the time - I don't know why yet, probably this goes from HBrowse; > 3) when I try to open my report forms, the designer simply hangs. > > I plan to investigate this problems deeper, but before I need to deal > with the current HwGUI code. As I wrote above, there are things, which I > don't like and which prevent me to upgrade to the newest version. There > is a lot of additions, I believe that they are useful and really makes > HwGUI better. The problem is with structure. > > From the beginning I tried to make HwGUI compact and fast. My code > wasn't ideal ( now it is a bit better :), and I hope it will better in > future - we all are learning till the end of the life ) and there was > fragments which I don't like. But now, from the point of a class > structure, the things became even worse. I believe, that classes, > especially basic classes, which have many objects, should have minimum > of variables and methods - only that, which are really necessary. When > HCustomWindow has some redundant variables and methods, the HControl, > which inherits from it, adds new redundant, the final, for example, most > frequently encountered HStatic has a number of redundant stuff. We have > a lot of HStatic, HEdit, etc. objects in a form, each of them contains a > lot of rubbish, which makes their response time bigger, though they > never use it. > Why the response time become bigger ? Each control gets a lot of > Windows messages, each message is handled in HwGUI code to find > appropriate method and execute it. The more methods and vars has the > object, the more time is needed to find necessary one. > To be more concrete, I consider the following methods of > HCustomWindow as redundant: ResetScrollbars(), SetupScrollbars(), > RedefineScrollbars() - because they don't needed for most controls, > which inherits from HCustomWindow; GetParentForm() - from my point, it > is better to write as a function; Hcontrol: FontBold(), FontItalic(), > FontUnderline() - I don't see any reson why they should be separate > methods. These are only examples, just to clarify my point. There is > more stuff which, in my opinion, should be cleared. > The second important thing is adding of new features to controls. Look > at HBrowse or HEdit - they became so big that it is very difficult to > review and understand their work. I believe that most of these new > features are useful, but why we put them into the same class ? We > absolutely forget about such thing as Inheritance ( the only good > exception is the HButtonEx by Luiz - but, IMO, it should be placed in > separate file ). I prefer to have simple control classes with basic > features, which are demanded in most cases and inherited from them, > maybe multiply, "ex" classes - for to keep basic set clean, fast and > readable. > > So, I suggest to rewrite some parts of HwGUI in accordance with these > thoughts and I'd like to hear your opinions. > > Regards, Alexander. > > P.S. Uff... I hate to write such a long texts, especially on English :) > > |
|
From: Alexander S.K. <al...@be...> - 2012-12-13 09:47:19
|
Hi All, for a long time I didn't follow the HwGUI development. For my projects I still use an old version, which is about 4 -5 years old. Sometimes, quite rarely, I did necessary changes and uploaded them here. I didn't use the renewed HwGUI from the SF repository because of a big number of changes, for which I hadn't time and energy to review and to check. From time to time I reviewed the new code partially and returned to my old version because I found there many things, which I don't like. Recently I was asked to review the Designer, because it has serious problems. I've build it with a latest HwGUI code and Harbour 3.2 and really found some: 1) incorrect appearance of non-English characters in some places - this resolves very easy by setting appropriate codepage; 2) object inspector - the selected items remains coloured as selected al the time - I don't know why yet, probably this goes from HBrowse; 3) when I try to open my report forms, the designer simply hangs. I plan to investigate this problems deeper, but before I need to deal with the current HwGUI code. As I wrote above, there are things, which I don't like and which prevent me to upgrade to the newest version. There is a lot of additions, I believe that they are useful and really makes HwGUI better. The problem is with structure. From the beginning I tried to make HwGUI compact and fast. My code wasn't ideal ( now it is a bit better :), and I hope it will better in future - we all are learning till the end of the life ) and there was fragments which I don't like. But now, from the point of a class structure, the things became even worse. I believe, that classes, especially basic classes, which have many objects, should have minimum of variables and methods - only that, which are really necessary. When HCustomWindow has some redundant variables and methods, the HControl, which inherits from it, adds new redundant, the final, for example, most frequently encountered HStatic has a number of redundant stuff. We have a lot of HStatic, HEdit, etc. objects in a form, each of them contains a lot of rubbish, which makes their response time bigger, though they never use it. Why the response time become bigger ? Each control gets a lot of Windows messages, each message is handled in HwGUI code to find appropriate method and execute it. The more methods and vars has the object, the more time is needed to find necessary one. To be more concrete, I consider the following methods of HCustomWindow as redundant: ResetScrollbars(), SetupScrollbars(), RedefineScrollbars() - because they don't needed for most controls, which inherits from HCustomWindow; GetParentForm() - from my point, it is better to write as a function; Hcontrol: FontBold(), FontItalic(), FontUnderline() - I don't see any reson why they should be separate methods. These are only examples, just to clarify my point. There is more stuff which, in my opinion, should be cleared. The second important thing is adding of new features to controls. Look at HBrowse or HEdit - they became so big that it is very difficult to review and understand their work. I believe that most of these new features are useful, but why we put them into the same class ? We absolutely forget about such thing as Inheritance ( the only good exception is the HButtonEx by Luiz - but, IMO, it should be placed in separate file ). I prefer to have simple control classes with basic features, which are demanded in most cases and inherited from them, maybe multiply, "ex" classes - for to keep basic set clean, fast and readable. So, I suggest to rewrite some parts of HwGUI in accordance with these thoughts and I'd like to hear your opinions. Regards, Alexander. P.S. Uff... I hate to write such a long texts, especially on English :) |
|
From: Basso, L. F. <lf...@vi...> - 2012-12-07 13:11:22
|
yes! Thanks Regards, Luis fernando Basso -----Mensagem Original----- From: oleksa Sent: Friday, December 07, 2012 10:56 AM To: hwg...@li... Subject: Re: [Hwgui-developers] [Hwgui-commits] SF.net SVN:hwgui[1949]trunk/hwgui Thank you, hwgui builded ok, but we have Rascan func again, please, use a #ifdef __XHARBOUR__ #xtranslate hb_RAScan([<x,...>]) => RAScan(<x>) #endif Regards, Alexey Myronenko ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Hwgui-developers mailing list Hwg...@li... https://lists.sourceforge.net/lists/listinfo/hwgui-developers |
|
From: oleksa <m.o...@uk...> - 2012-12-07 12:56:12
|
Thank you, hwgui builded ok, but we have Rascan func again, please, use a #ifdef __XHARBOUR__ #xtranslate hb_RAScan([<x,...>]) => RAScan(<x>) #endif Regards, Alexey Myronenko |
101 messages has been excluded from this view by a project administrator.
