FiveTech Software tech support forums

Hello

I expext a behaviour as in clipper :

K Deletes default text if first key is not a cursor
key.

I don't know how to impliment this in FWH . Maybe in the rc-file ?

Frank

Frank,

I remember this was a bug many years ago. Are you saying that it isn't working now using the standard Clipper picture syntax?

James

James,

Yes , it is not working in fwh8.10 , when the get receives focus from the mouse

I found a thread that describes the problem :

viewtopic.php?f=3&t=8631&p=40346&hilit=get+and+picture#p40346

Frank

Frank,

OK, I reviewed the old message thread and I see the problem. My fix only works when you Tab into the field and the cursor is in position 1. If you click into the field in any position other than 1, then my fix doesn't work.

I looked at the TGet code a little, and we have to figure out how to detect the first keystroke after the field has been clicked into. I am not sure how to do this.

Antonio, any ideas? Or, anyone?

Regards,
James

Frank,

I think this might be a perception problem. Here is the orinigal poster's description of the problem:

I have a problem when using "@K" picture clause. If I have several controls on a window or dialog and the user tabs or presses enter to move through the controls the get text is correctly deleted if they user types a character in a get. However, if the user clicks on a control using the mouse and types a character the text of the get is not deleted and the character typed is simply inserted (or overwrites) the text in the control.

Can someone confirm (or not) this problem?

Clipper Help for @K picture:
Deletes default text if first key is not a cursor key

xHarbour help:
Allows a suggested value to be seen within the GET
area but clears it if any non-cusor key is pressed when
the cursor is in the first Position in the GET area.

Note that with Clipper you cannot click into a field, so the only way to get there is to use the Enter key. So, with Clipper you cannot enter the field in any position other than the first position.

Note also that the xHarbour help file specifically states that it clears the Get if "the cursor in in the first position in the Get area." The original poster assumed that the Get should be cleared if any non-cursor key was typed after clicking into the Get in any position. Perhaps this behavior is desirable, but it is not the way Clipper's Gets worked and thus is not the way xHarbour's Gets work (by design). [Remember that FWH's TGet class contains a xHarbour (or Harbour) Get object.]

So, the current behavior is not a bug, it is true to Clipper's Get's behavior. The question becomes should this behavior be changed, or at least optional, in the Windows environment. I don't know if it would be possible to get a consensus on doing this to the xHarbour/Harbour Get class since they like to remain true to Clipper. And, I don't know if this can be done in the FWH TGet class.

Regards,
James

I guess a pure Harbour app is console based and thus cannot be clicked on with a mouse cursor. So, any changes to allow clicking anywhere to work as descibed would have to be made the FWH TGet class.

Regards,
James

James Bott wrote:I guess a pure Harbour app is console based and thus cannot be clicked on with a mouse cursor. So, any changes to allow clicking anywhere to work as descibed would have to be made the FWH TGet class.

Regards,
James

I tryed with xharbour AND clipper 5.3b , the k-clausule works when the first character from a get is clicked and then a key is pressed

It is very confusing , only after reading the previous thread i understood when the k-clausule doesn't work.

Also mine users have no idea when it works and when not

Frank

I used a product called Provision Windows a long time ago. It was a dos based windowing product for clipper. With it you could click on the "label" for the field and it would put you into the first position of the field with the @K active.

Gale,

With it you could click on the "label" for the field and it would put you into the first position of the field with the @K active.

This should be fairly easy to implement using the GotFocus() method. It would be more difficult if the user clicks on the field in any position other than the first and then starts typing.

Here is how the IE address field works. If you click on it anywhere, the entire address is highlighted and the cursor is at the last position (of the address). If you then start typing, the entire address is erased and your keystroke is in the first position.

I have not looked at other applications to see how they work.

I think we need to come to a general agreement about how it should work before suggesting a solution.

James

Frank,

I tryed with xharbour AND clipper 5.3b , the k-clausule works when the first character from a get is clicked and then a key is pressed

Can you click anywhere other than the first character and have the cursor remain there or does it jump to the first character?

I am not sure we should be emulating DOS apps anyway. We are in a Windows world now, and should probably be emulating the most common behavior in Windows apps.

James

Good Morning.

Sorry my english!

This problem solved:

oget:refresh(.t.)
oget:setpos(0)
oget:setfocus()


bye

Dear James:

James Bott wrote:This should be fairly easy to implement using the GotFocus() method. It would be more difficult if the user clicks on the field in any position other than the first and then starts typing.

Here is how the IE address field works. If you click on it anywhere, the entire address is highlighted and the cursor is at the last position (of the address). If you then start typing, the entire address is erased and your keystroke is in the first position.
I think we need to come to a general agreement about how it should work before suggesting a solution.

IMHO it should the buffer to be cleared at the first keystroke no matter where the cursor was positioned by the mouse. As you said, a SelectAll() could be a good option.

Best regards.

If you are talking about filling out forms or a screen of information then it seems there are at least 4 types of people/scenarios.
1. Someone who likes to use a mouse for everything possible.
2. Someone that wants to skip ahead on the page.
3. Someone that needs to go back and correct something on the page.
4. Someone that uses keyboard to go forward and back.

Type 1 I don't know which way would be preferable. But if it is a lot of editing instead of adding I would say not to highlight entire field when click into it.
Type 2 would probable be ok with highlight entire field.
Type 3 would probably prefer correct positioning.
Type 4 already taken care of.