Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Textbox readonly problem

Status
Not open for further replies.

aharrisreid

Programmer
Nov 17, 2000
312
GB
In my foundation textbox class, if I want to prevent a user changing the value I prefer to make it readonly rather than disabled. The main reason for this is that if the current value is too long for the visible area of the control, the user can still press the right-arrow or end-key to see the full contents (or press Ctrl+c for copying). The downside of this approach is that pressing enter or tab to exit field fires the valid event, often running unnecessary code and sometimes having undesired effects.

One way round this problem is to check for this.readonly=.F. before running validation code, but this would be a pain for every valid event (or lostfocus, come to think of it) which has code.

Apart from making the control disabled instead of readonly, is there any other way around this problem? BTW, I am using VFP7.

Any help would be appreciated.

Alan
 
Hello Alan.

>> One way round this problem is to check for this.readonly=.F. before running validation code, but this would be a pain for every valid event (or lostfocus, come to think of it) which has code. <<

This is not just an issue for controls that are ReadOnly. It is an issue any time the user tabs through a control without changing anything. That is why all of my data bound base classes have a custom proerty called uOldVal that gets set in GotFocus like so:

Code:
This.uOldVal = This.Value

The, before calling any custom methods from Valid() or LostFocus(), I can check to see if the user actually changed the value of the control before running any ( unnecessary ) code.

Just a thought....





Marcia G. Akins
 
Hi Marcia, thanks for the reply.

>The, before calling any custom methods from Valid() or >LostFocus(), I can check to see if the user actually >changed the value of the control before running any ( >unnecessary ) code.

If I understand you correctly, does this mean you place the change-check code in the Valid() of the base-class, so that the following code can go in the form control?
IF DODEFAULT()
validate this control
ENDIF

myBaseTextBox.valid()
IF this.value=this.uOldVal && ie. no change
RETURN .F.
ENDIF

Regards,
Alan
 
Hi Alan.

>> If I understand you correctly, does this mean you place the change-check code in the Valid() of the base-class, so that the following code can go in the form control?

IF DODEFAULT()
validate this control
ENDIF <<

No, this is not correct. I save the control's value to This.uOldVal in the GotFocus() of the base class, but there is no code in the the base class's Valid(). If there is code in the Valid(), it is always instance specific - this is because a textbox, for example, can be bound to many different data types so I have no way of knowing how to do this comparison:

Code:
IF NOT( NVL( This.uOldVal, '' ) == NVL( This.Value, '' ) )
  *** The user actually made a change
  *** Do something




Marcia G. Akins
 
Hi Marcia,

>...a textbox, for example, can be bound to many different
>data types so I have no way of knowing how to do this
>comparison:
>IF NOT( NVL( This.uOldVal, '' ) == NVL( This.Value, '' ) )

I am probably missing something here, but why not? Is it not a fairly safe assumption that VARTYPE(this.uOldVal)=VARTYPE(this.value)? In other words, can the data type change between GotFocus() and Valid()?

Any further explanation would be appreciated.

Many thanks,
Alan
 
Hello Alan.

>> I am probably missing something here, but why not? Is it not a fairly safe assumption that VARTYPE(this.uOldVal)=VARTYPE(this.value)? <<

Yes. That is a safe assumption. What is not a safe assumption is that VARTYPE( NVL( This.uOldVal, '' ) ) = VARTYPE( NVL( This.Value, '' ) ). If, for example, uOldVal is .NULL. and the value is {04/02/2004} this comparison is going to result in a data type mismatch error.



Marcia G. Akins
 
You have the option of adding a property to the textbox in your foundation class, similar to adding a property on a form. Can't you use a property to determine the mode you are in? If so, you can modify the valid event to return .T. (or .F.) instead of firing the code.



Jim Osieczonek
Delta Business Group, LLC
 
Hi Marcia,

>If, for example, uOldVal is .NULL. and the value is
> {04/02/2004} this comparison is going to result in
> a data type mismatch error.

Good point, I understand now, but how about if we use
TRANS(NVL(This.uOldVal,''))==TRANS(NVL(This.value,''))?
There is probably a fundamental flaw in this, but at least both sides of the equation would be character.

Regards,
Alan


 
Hi Jim,

>You have the option of adding a property to the textbox
> in your foundation class, similar to adding a property
> on a form. Can't you use a property to determine the
> mode you are in?

I don't quite understand. What do you mean by mode? We already have the .readonly property, couldn't we use that?

>If so, you can modify the valid event to return .T.
> (or .F.) instead of firing the code.

I think I see what you are getting at now. You could test for 'IF value has changed' in the form-specific textbox, but what I am aiming for is a generic solution that can be used as default beheviour in the textbox base-class Valid().

Hoping I have understood you correctly...

Alan




 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top