Page 1 of 2

non-standard behavior

PostPosted: Thu Dec 15, 2011 5:23 pm
by MarcoBoschi
Hi,
If I run this little program ....
#include "fivewin.ch"

#define crlf CHR(13)+CHR(10)


FUNCTION main()
LOCAL oDlg
LOCAL oGet1 , cGet1 := "Aaaaa " + crlf + "Bbbbbbb "
LOCAL oGet2 , cGet2 := "Cccccc Dddd Eeeeee "

DEFINE DIALOG oDlg

@ 1 , 1 GET oGet1 VAR cGet1 OF oDlg SIZE 100 , 30 PIXEL MEMO

@ 3 , 1 GET oGet2 VAR cGet2 OF oDlg

ACTIVATE DIALOG oDlg CENTER

RETURN nil
... it's evident that the behavior of this program is not standard.

All my programs behave the same way, especially for:

- it selects all get content if I enter in the get object using TAB key
- if I click with mouse in the get object over the last character cursor is positioned at the last character
- If I select in memo field two rows of text If I paste in a single line get only first line is copied
The list ends here!

Another consideration is: If I introduce some modifications to achieve a normal behavior I lose some features that I have to create them to play them one by one, unsuccessfully.

The question: is there a solution to resolve the three listed problems?

King regards

marco

Re: non-standard behavior

PostPosted: Thu Dec 15, 2011 5:38 pm
by Antonio Linares
Marco,

1. Do you mean when the MEMO gets focus ? All text is selected, right ?

2. I don't understand what you mean here. What is the problem ?

3. Here it is working fine. I select the two lines of your example and then paste them in UEStudio and they are there

Re: non-standard behavior

PostPosted: Thu Dec 15, 2011 5:45 pm
by MarcoBoschi
Antonio,
is it a version problem?
I use a version october 2009.

Re: non-standard behavior

PostPosted: Thu Dec 15, 2011 5:51 pm
by MarcoBoschi
>1. Do you mean when the MEMO gets focus ? All text is selected, right ?
Using TAB key when I enter a GET all get content has to be selected MEMO GET and normal GET

>2. I don't understand what you mean here. What is the problem ?
If I click in a GET cursor position has to be adapted to the ALLTRIM( oget:varget() ) that ias at the end of the last character

>3. Here it is working fine. I select the two lines of your example and then paste them in UEStudio and they are there
I'm talking about the possibility to select multiple line and paste in a single line
STRTRAN( cTmp , crlf , " " ) for instance

many thanks
marco

Re: non-standard behavior

PostPosted: Thu Dec 15, 2011 6:06 pm
by Antonio Linares
Marco,

FWH users usually don't want that GETs text gets automatically selected as when the user types something all the content is erased.

Do you want all the text to be selected ? (in fact that is the standard behavior)

Re: non-standard behavior

PostPosted: Thu Dec 15, 2011 7:34 pm
by Gale FORd
It seems to me that if the picture has "@K" in it, then all text should be selected when tab, arrow, or enter key was used prior to the get.
This gives the user a visual clue that if they type a letter all text gets cleared.

Re: non-standard behavior

PostPosted: Fri Dec 16, 2011 12:54 pm
by MarcoBoschi
>> Do you want all the text to be selected ? (in fact that is the standard behavior)
Yes! My customers want

Re: non-standard behavior

PostPosted: Fri Dec 16, 2011 12:59 pm
by MarcoBoschi
To Gale
>It seems to me that if the picture has "@K" in it, then all text should be selected when tab, arrow, or enter key was used prior to the >get.
>This gives the user a visual clue that if they type a letter all text gets cleared.
with PICTURE "@K" it's the same
If users accidently type a letter and delete all selected text, pressing CTRL_Z or Right Mouse Undo they return to previus value.

Re: non-standard behavior

PostPosted: Fri Dec 16, 2011 2:15 pm
by Gale FORd
It sounds like you want selectall on all the fields but to me it should only be that way only if you use a picture with "@K".
Without "@K" it should act normally.
I modified tget and mget so that it would do a selectall when picture includes a "K" like "@K" .
My users appreciate the visual clue that selectall provides.

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 8:44 am
by MarcoBoschi
In this little sample I select all get content using TAB key.
But If I press a "X" character I find (in second get)
X instead of Cccccc Ddddd Eeeeeeee
If I press CTRL_Z or Right mouse to Undo this accidental error
I cannot undo this operation.

Any hints?

King regard

Marco

Code: Select all  Expand view
#include "fivewin.ch"

#define crlf CHR(13)+CHR(10)


FUNCTION main()
   LOCAL oDlg
   LOCAL oGet1   , cGet1   := "Aaaaa " + crlf + "Bbbbbbb "
   LOCAL oGet2   , cGet2   := "Cccccc Dddd Eeeeee           "

   DEFINE DIALOG oDlg

   @ 1 , 1 GET oGet1 VAR cGet1 OF oDlg SIZE 100 ,  30 PIXEL MEMO
   oGet1:bGotFocus := { || entraget( oGet1 ) }

   @ 3 , 1 GET oGet2 VAR cGet2 OF oDlg
   oGet2:bGotFocus := { || entraget( oGet2 ) }

   ACTIVATE DIALOG oDlg CENTER

RETURN nil

FUNCTION ENTRAGET( oGet )
LOCAL nPos1 := oGet:nPos
LOCAL nPos2 := 1

IF GetKeyState( VK_LBUTTON )
   IF nPos1 < Len( RTrim( oGet:varget() ) )
      nPos2  := nPos1     +1
   ELSE
      nPos2  := Len( RTrim( oGet:varget() ) )+ 1
   ENDIF
   oGet:SetPos( nPos2 )

ELSE
   oGet:SelectAll()

ENDIF

RETURN NIL

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 11:16 am
by Antonio Linares
Marco,

To have 100% standard behavior on GETs please replace all the code in Class TGet that follows:

case nKey >= 32 .and. nKey < 256

with

return nil

but the problem is that then we loose Clipper GETs compatibility. We need to find a way to make them compatible there.

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 12:11 pm
by Antonio Linares
Ok, I think I have the right solution:

We are going to implement a new Class TEdit that uses a standard Windows Edit control with no related Clipper/Harbour GET at all, this way everything will be fine: Unicode support, etc :-)

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 1:00 pm
by MarcoBoschi
:D :D :D :D :D

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 4:35 pm
by richard-service
Antonio Linares wrote:Ok, I think I have the right solution:

We are going to implement a new Class TEdit that uses a standard Windows Edit control with no related Clipper/Harbour GET at all, this way everything will be fine: Unicode support, etc :-)

Sounds good. Long time ago, I suggestion it for Chinese input within Winxp Themes and Unicode.
FWH need TEdit Class for Windows Edit control. Some develop tools( MiniGUI, -..) had it.

Re: non-standard behavior

PostPosted: Tue Dec 20, 2011 4:40 pm
by Antonio Linares
Well, in fact it is already available and included in FWH :-)

FWH\source\classes\edit.prg

and an example:

samples\testedit.prg