Cursor control in a form. How to prevent cursor from going to next textbox

[TinyNinja]

Hello everyone,

In my form I have multiple textboxes and the user will automatically go to the next box after filling out the info in the first. My question is how do I prevent the cursor go to go the next textbox in the list?
So user_A types into textbox_1 and I have a check to make sure the character length is longer than 4 and if it is then move cursor to textbox_2 but if it is not then I want the cursor to stay on textbox_1 until the user types the correct amount of characters. How would I do this?
I have played with putting different things in the valid and lostfocus area of the to no luck.

Please help!
Thanks

 

[Olaf Doschke]

It's a bad practice to make use of individual validation, but valid is the right choice for that. You return 0 or .f. to stay.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[TinyNinja]

Is there another way to do the check before allowing the user to go to the next textbox?

 

[Olaf Doschke]

No, the recommended way is to check a full record and not single fields, as you can easily lock a user in a situation needing to leave a form with such a validation.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

I second what Olaf says. Although you can use the Valid event to prevent the user moving to the next control, it is better practice to defer that kind of validation until just before you commit the data. You have probably been in a situation yourself where you have become "trapped" in a control and don't know how to get out of it. Using Valid raises that possibility.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tom Borgmann]

Hi TinyNinja,

how about putting the cart before the horse
Instead of preventing to leave a textbox, you could simply disable the following textboxes and enable them as soon as the previous textbox is correctly filled.
Or by using a textbox class that has a red background as long as its content is missing of fault.
Checking for missing length can be done via .interactiveChange property

something like that in the interactivechange prop should do:

IF LEN( ALLTRIM(This.Value) ) >= 4
	This.BackColor = RGB(255,255,255)
ENDIF

Just replace the 4 with the valid minimum length which could be individually defined by a special property of the textbox.


HTH

-Tom

https://www.blogger.com/profile/08903165976787522012

 

[Olaf Doschke]

Taking Tom's idea you would turn the backcolor red as default, but then not get back to red when a user types 4 characters and afterwards empties the box.

I also don't like a mixture of default setting and code, even though it's no error. I often miss a ResetToDefault() to make sense of the default value, either there is no reset at all or the reset is done to the specific value.

In short, there is a way I think would be most consistent, as all colorc-hanges only happen in one place:

In textbox Init(), InteractiveChange(), and Refresh() have:

This.RefreshState()

In the new RefreshState method have:

IF LEN( ALLTRIM(This.Value) ) >= 4
	This.BackColor = RGB(255,255,255)
ELSE
	This.BackColor = RGB(255,96,96)
ENDIF

Perhaps even have an include file defining the colors for sufficient/insufficient input.

And now there are more variants depending on your philosophy of encapsulation. If you look at it from the perspective of the single text box that's encapsulated this way in a decent way to not block the rest, but you could also see it from the perspective of encapsulating all code that handles form validation in one single point, so it's all together. That could be form.validaterecord or part of the cursoradapter or other data access/business logic class object also handling the fetching of data and saving changed data. There4 are good reasons against putting this into the data access, as that's binding it to that specific form, actually indicating wrong data is a frontend job, but knowing the rules indeed is a job of the code to verify correct data before saving completely independent of the form used for the input/editing. So to make this perfect in the sense of good OOP programming the control should not have the rule for correct input encoded, he'll need to ask the business logic if the input is correct:

In the new RefreshState method have:

IF This.oBizRules.IsValid(This.ControlSource, This.Value)
	This.BackColor = VALIDCOLOR
ELSE
	This.BackColor = INVALIDCOLOR
ENDIF

Instead of passing both ControlSource and Value only THIS might be passed, but then such an IsValid validation method of a biz rules class would need specific knowledge about what control has which properties, it's sometimes also the RecordSource or Rowsource, that's important. To pass in the Value also is necessary, as the field specified in the ControlSource will only be updated to the display value, when you leave the control, the current value only is in the control.Value property.

In this form of the code this can be put into a data entry textbox used for anything and the rule is checked by whatever business object is set for the textbox. The task of validation is centralized and encapsulated on the level of the whole table in a class that's usable not only in this one form, but any form also used to maintain the same data, in more complex applications that can easily be the case.

To summarize: The native events and methods are not good for a good OOP style of programming, they tempt you to do very local and specific code that's not good on a larger scale. You can complicate it as much as you like or not like and you can set the boundaries of the OOP encapsulation rule differently, that's somewhat a matter of taste, too.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name