FiveTech Support Forums

FiveWin / Harbour / xBase community
Board indexActive topicsAll discussionsLogin (GitHub)
Board index FiveWin for Harbour/xHarbour Problem with TGET class in FWH 13.08
driessen
Posts: 1467
Joined: Mon Oct 10, 2005 11:26 AM
Problem with TGET class in FWH 13.08
Posted: Thu Sep 26, 2013 03:02 PM
Hello,

A customer of mine notice a problem in a get field since the latest FWH 3.08.

First of all, my dates are character fields because I have made my own control to check if the date is correct, if it is a weekend of a holiday, etc.

This is the code I use :
Code (fw): Select all Collapse
REDEFINE GET oGET[12] VAR cAGDATUM ID 115 OF AgeDlg PICTURE "99/99/9999" UPDATE VALID DatContr("cAGDATUM",AgeDlg,,.T.) .AND. CtrWeekDay("cDOW1",cAGDATUM,.T.,AgeDlg,cContrW1,"cContrW1","oAGDATUM")
oGET[12]:bGotFocus  := {|| SYSREFRESH(),oGET[12]:Assign(),oGET[12]:SetSel(0,LEN(RTRIM(cAGDATUM  )))}
The second line takes care that the GET is selected completly if the GET gets the focus.

If the date has to be changed by the customer, he often clicks in the GET and select the whole date. Then he enters the new date.

In FWH 13.07 that was no problem at all. In FWH 13.08, he has to push the delete-button or the home-button of his keyboard first to enter the new date. This wasn't the case in FWH 13.07. He could start typing the new date inmeddiately.

I noticed 2 minor changes into the TGET class of FWH 13.08 :
Code (fw): Select all Collapse
::npos = ::oGet:pos
has been changed in
Code (fw): Select all Collapse
::npos = nHi + 1 // don't use ::pos here! as it does not allow any higher values

Code (fw): Select all Collapse
::nPos--
has been changed in
Code (fw): Select all Collapse
::nPos = Len( ::oGet:Buffer ) + 1
::oGet:Pos = ::nPos
The reason for the chance of behaviour, must be in one of those changes in the TGET class.

Anyone any idea?

Thanks a lot in advance for any help.

Regards,

Michel D.
Genk (Belgium)

_____________________________________________________________________________________________

I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773

Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Thu Sep 26, 2013 03:24 PM
Michel,

Could you try this example and check if it works fine there ? Here it is working fine:

Code (fw): Select all Collapse
#include "FiveWin.ch"

function Main()

   local oDlg, oGet, dDate := Date()

   DEFINE DIALOG oDlg

   @ 2, 2 GET oGet VAR dDate 

   oGet:bGotFocus = { || oGet:SetSel( 0, 8 ) }

   ACTIVATE DIALOG oDlg CENTERED

return nil
regards, saludos

Antonio Linares
www.fivetechsoft.com
driessen
Posts: 1467
Joined: Mon Oct 10, 2005 11:26 AM
Re: Problem with TGET class in FWH 13.08
Posted: Thu Sep 26, 2013 06:24 PM
Antonio,

I did your the test you send me.

First I tested it with FWH 13.07 -> no problem everything ok
Then I tested it with FWH 13.08 -> I noticed the same problem. If I select the complete date with my mouse and I want to type another date, nothing happens until I have pressed the home- or the delete button on my keyboard.

Conclusion : the problem also occurs in your test, just I experienced in my application.

You can download a ZIP-file (which I renamed to ZOP for security reasons). This file contains 2 executables :

T1307.EXE : executable with FWH 13.07
T1308.EXE : executable with FWH 13.08

This is the link : http://www.ma-consult.be/test.zop. Please let me know when you have downloaded the ZIP-file (ZOP).

Good luck.

Thanks.

Regards,

Michel D.
Genk (Belgium)

_____________________________________________________________________________________________

I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773

Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Thu Sep 26, 2013 08:55 PM
Michel,

This seems to be the right fix. In Class TGet Method KeyChar:

The + 1 makes the difference. Thanks! :-)
Code (fw): Select all Collapse
      case nKey >= 32 .and. nKey < 256
           if ::oGet:buffer == nil
              return 0
           endif
           if ::nPos > Len( ::oGet:buffer ) + 1
              return 0
           endif
regards, saludos

Antonio Linares
www.fivetechsoft.com
driessen
Posts: 1467
Joined: Mon Oct 10, 2005 11:26 AM
Re: Problem with TGET class in FWH 13.08
Posted: Thu Sep 26, 2013 09:39 PM

Antonio,

Thank you very much. The problem has been solved. Great work.

I presume that the correction will be in FWH 13.09.

Have a good night.

Regards,

Michel D.
Genk (Belgium)

_____________________________________________________________________________________________

I use : FiveWin for (x)Harbour v. 25.12 - Harbour 3.2.0 (May 2025) - xHarbour Builder (January 2020) - Bcc773

Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Fri Sep 27, 2013 01:38 PM

Michel,

Yes, its already included for FWH 13.09, thanks :-)

regards, saludos

Antonio Linares
www.fivetechsoft.com
James Bott
Posts: 4840
Joined: Fri Nov 18, 2005 04:52 PM
Re: Problem with TGET class in FWH 13.08
Posted: Fri Sep 27, 2013 05:08 PM

Michel,

You may also want to add the picture clause:

...PICTURE "@K"

This erases the default text when the first key typed is not a cursor. Then the users would not have to highlight the entire default text before they start typing.

It is really too bad that this is not the default behavior of GETs (without adding the picture clause).

Regards,
James

FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Fri Sep 27, 2013 10:40 PM

James,

I agree with you, but that would not be Windows standard where if the text is selected, then it is erased, when typing.

regards, saludos

Antonio Linares
www.fivetechsoft.com
Enrico Maria Giordano
Posts: 9022
Joined: Thu Oct 06, 2005 08:17 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sat Sep 28, 2013 07:28 AM
Antonio,

Antonio Linares wrote:I agree with you, but that would not be Windows standard where if the text is selected, then it is erased, when typing.


This is the Windows standard. Or am I missing something?

EMG
Enrico Maria Giordano

e.m.giordano@emagsoftware.it
http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg
Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sat Sep 28, 2013 07:53 AM

Enrico,

What I understood from James is that it should be the default behavior but without having to select the text.

Thats why I commented that in such case it would not be a standard behavior :-)

regards, saludos

Antonio Linares
www.fivetechsoft.com
Enrico Maria Giordano
Posts: 9022
Joined: Thu Oct 06, 2005 08:17 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sat Sep 28, 2013 09:12 AM
Antonio,

Antonio Linares wrote:Enrico,

What I understood from James is that it should be the default behavior but without having to select the text.

Thats why I commented that in such case it would not be a standard behavior :-)


That's what I understood too. And I confirm this is the Windows standard behavior: when a edit box gains the focus the text inside it become selected. Am I wrong?

EMG
Enrico Maria Giordano

e.m.giordano@emagsoftware.it
http://www.emagsoftware.it
http://www.emagsoftware.it/emgmusic
http://www.emagsoftware.it/spectrum
http://www.emagsoftware.it/tbosg
Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sat Sep 28, 2013 11:44 AM

Enrico,

You are right :-)

regards, saludos

Antonio Linares
www.fivetechsoft.com
James Bott
Posts: 4840
Joined: Fri Nov 18, 2005 04:52 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sun Sep 29, 2013 02:30 PM
Antonio,

I agree with you, but that would not be Windows standard where if the text is selected, then it is erased, when typing.


It has been some time since I looked at this. I just did a little reviewing.

Standard Windows behavior seems to be that when you tab into a field all the text is highlighted, the cursor is after the last character, and the default text does vanish if you begin to type. If you click into a field the text is not highlighted and your typing overwrites the default text at the cursor's location. [I used Microsoft's Outlook Express for this testing.]

I note that FW's GETs do not have standard Windows behavior. When you tab into a field the cursor is in the first location (not the last) and nothing is highlighted (not Windows standard). When you begin to type, the text is overwritten at the current cursor location (Windows standard), but since the cursor is at the first location the default text is being overwritten one character at a time.

Granted, as you pointed out, the "@K" picture is not standard either and is probably not a good fix.

Perhaps it is worth considering either changing the default behavior of GETs to the Windows standard, or a least having a global option of setting all GETs to the Windows standard.

I know the GET's current behavior has been inherited from the old Clipper behavior, but now Clipper behavior seems irrelevant. I'm not sure how easy it would be to change the default behavior without (x)Harbour being changed.

Regards,
James

Code (fw): Select all Collapse
/*
Purpose: Test @K picture in a GET
*/

#include "fivewin.ch"

function main()
   local oDlg
   local oGet1, oGet2, cVar1:="House     ", cVar2:="Boat   "
   define dialog oDlg
   @ 2,2 get oGet1 var cVar1
   @ 4,2 get oGet2 var cVar2  picture "@K"
   activate dialog oDlg centered
return nil
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Antonio Linares
Posts: 44162
Joined: Thu Oct 06, 2005 05:47 PM
Re: Problem with TGET class in FWH 13.08
Posted: Sun Sep 29, 2013 07:57 PM

James,

FWH also provides the Class TEdit which uses a standard Windows Edit control and does not mess at all with Harbour GETs :-)

Please review samples/testedit.prg

regards, saludos

Antonio Linares
www.fivetechsoft.com
James Bott
Posts: 4840
Joined: Fri Nov 18, 2005 04:52 PM
Re: Problem with TGET class in FWH 13.08
Posted: Mon Sep 30, 2013 03:57 PM
Antonio,

FWH also provides the Class TEdit which uses a standard Windows Edit control and does not mess at all with Harbour GETs


I didn't know about it. Looks great. I assume we can define them as resources?

Regards,
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Static archive · New replies & topics via GitHub Discussions