FiveTech Software tech support forums

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: Select all  Expand view

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: Select all  Expand view

::npos = ::oGet:pos

has been changed in

Code: Select all  Expand view

::npos = nHi + 1 // don't use ::oGet:pos here! as it does not allow any higher values

Code: Select all  Expand view

::nPos--

has been changed in

Code: Select all  Expand view

::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.

Michel,

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

Code: Select all  Expand view

#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

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.

Michel,

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

The + 1 makes the difference. Thanks!

Code: Select all  Expand view

     case nKey >= 32 .and. nKey < 256
           if ::oGet:buffer == nil
              return 0
           endif
           if ::nPos > Len( ::oGet:buffer ) + 1
              return 0
           endif

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.

Michel,

Yes, its already included for FWH 13.09, thanks

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

James,

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

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,

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

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,

You are right

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: Select all  Expand view

/*
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
 

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

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