How to bypass Valid event of a Textbox 2

[Rajesh Karunakaran]

Hi Team,

I have a textbox and a command button in a form. The command button is to exit from the form. Textbox has some code in its Valid method. It invokes a help list (another form) if the textbox value is empty. Now, when the focus is in the textbox and when I click the command button, the Textbox Valid fires and the help list is shown. I have to then exit from the help list and once again click on the command button.

Is there anyway to avoid this second click?

I mean, something like to identify if I click on the command button when the focus is on the textbox and then to bypass the Valid event firing and directly run the command button code.

Thanks
Rajesh

 

[Mike Lewis]

The behaviour you are seeing is the correct behaviour; it is how the Valid event is designed to work. Normally, you would want the textbox to be validated, no matter how the user chooses to lose focus from it - whether by going to another control or clicking on the Close button.

One way round that would be to put the Close button on a toolbar instead of on the form. That way, the text box won't lose focus and the Valid won't fire. But be careful. If you have other controls on the form that have code in their Valid or LostFocus events, that code won't fire either. That might not be what you want.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

That Toolbar behavior also causes the infamous "last change not saved" bug, wehn you have a save button not saving the value of the currently focus control, as it didn't yet went through its Valid code.

Your choice to invoke a help list on valid is not ideal, valid is for validation only and to avoid such problems many here rather not make use of single control validation, but validate overall data in a save button.

What you can try is use the buttons When() event, that happens, before focus is moved to the button, so you're in the situation you know the button is clicked but still whatever focused control has the focus, aka Thisform.ActiveControl.

I still wouldn't go that route, because also simply tabbing through all controls you'll hang on such a help list just because you passed by. In fact just clicking anywhere else from this textbox you normally won't want to get a help list, but simply stay with the empty value and interact with whatever you move focus to. Why don't you change the activation of the help list via the textbox keypress when "Arrow Down" key was pressed, for example?

Bye, Olaf.

 

[Mike Lewis]

What this boils down to is this: Are users allowed to close the form if the textbox is empty? If yes, then showing the help seems not to make sense. If no, then you shouldn't be allowing them to reach the Close button if the textbox is empty, so the situation wouldn't arise.

But in any case, I agree with Olaf that you shouldn't be showing the help simply because the user is passing focus through the textbox. Even when the textbox is empty, that doesn't mean that they need to see the help. They might have just forgotten to enter something, or they might want to reach another control before they do so. Much better to give them a way of calling up help on demand. Olaf suggested a down-arrow as a possible way to do that. I would prefer to see a more visible method, such as a small question mark that they can click on next to the textbox. But the exact mechanism isn't important. What matters is that they should only see the help if they ask for it.

Another issue: What is the exact purpose of the Close button? Obviously, you want it to close the form. But what happens to the data already entered? Do you want it to be saved? - in which case you are saving the empty textbox value, which I think is not what you want. Or do you want to close without saving, which doesn't seem to make much sense.

Maybe you need two separate button: a Save and a Revert. In that case, your data should be buffered, so that the Save button can commit the changes and the Revert button can cancel them. It would then make sense to have a separate Close button (which can only close the form if there is no buffered data). And then also do away with the Valid event, by putting the validation in the Save button.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Isn't there a button property that would override the textbox validation - Cancel

I set my quit button to be CANCEL = .t.

It only works for the escape key though I think.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Griff,

Setting a button's Cancel property to .T. simply means that if the user presses ESC, the button's Click event fires. The textbox will still lose focus, so the Valid will still fire.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

True Mike, but the valid could then check for the escape key having been pressed before doing whatever it was designed to

Local m.lRetVAL
m.lRetVAL = .F.
IF LASTKEY() <> 27
	** do normal validation here
	** IF Valid Set m.lRetVAL to .t.
ELSE
	** return .t. if lastkey was escape
	m.lRetVAL = .T.
ENDIF
RETURN(m.lRetVAL)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

Yes, that should work, Griff - as far as I can see (I haven't tested it). It does require the user either to click the Close button or hit ESC immediately after editing the textbox. For example, it wouldn't work if they tabbed to the button. But that might not matter.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I think you couldn't 'tab' out of the control without firing the valid, but not everyone would want to have to hit Escape either, if you had a kiosk app, you might not have an Escape key

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

>LASTKEY() <> 27
That is used quite often, yes. But it also has a downside, when you only use the mouse at the moment, LastKey() will stay 27 and so you can move through controls of other forms without validation if you make that the standard. See

http://fox.wikis.com/wc.dll?Wiki~SkipValidOnExit

>I think you couldn't 'tab' out of the control without firing the valid, but not everyone would want to have to hit Escape either

Correct. Therefore it boils down to giving the user a feature he needs to activate. I agree with Mike something visual is better at least for new users, but habits can also establish or already have established, if you do custom software for someone, he may ask for the down arrow behavior. Another already familiar thing is reacting to typing, VFP has the autocomplete feature, which you trigger by typing into the textbox.

Anyway, it boils down to never misuse the Valid() event for anything else but validation and maybe even don't use that feature, unless your users are used to the validation feedback for every single tiny step they take. Legacy FoxPro screens are that way, a "workflow" following a strict tab order, maybe even no mouse. Today's windows interface is different, multitasking capabilities are necessary. I once argued with a phone call interrupting your work, you then might, still in this application, open up a customer form. And are nagged by some validation. Give the user the freedom to move anywhere run multiple forms in parallel, etc.

Bye, Olaf.

 

[Mike Lewis]

it boils down to never misuse the Valid() event for anything else but validation and maybe even don't use that feature ....

That is very true. A better approach would be to do all the validation - the entire form - immediately before you commit your edits, which would typically be in the Save button or in a routine called from that button. This is a better user experience, as it doesn't constrain the user to enter fields in any particular order, perhaps postponing some of the entries until others have been done. It also allows you to do validations based on dependencies: Field A must be non-empty if and only if Field B contains a given value, for example.

Perhaps this would be a good time for Rajesh to come back and give us some feedback on everything we have suggested so far. We are at the stage of making a lot of guesses about what he wants to achieve.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Possibly an alternative to Mike’s suggestion. A property of the form, Cancel_Fired or something like that could tell your Textbox that the command button had been pressed.

In the methods of the Command button :

.MouseEnter(): Thisform.Cancel_Fired = .T.
.MouseLeave(): Thisform.Cancel_Fired = .F.

You could then test Thisform.Cancel_Fired in Textbox.valid()

Hope this helps - may need tidying!

Andrew

 

[Rajesh Karunakaran]

Dear Team!

Thank you all for your time and valuable inputs. Mike was suggesting "Perhaps this would be a good time for Rajesh to come back and give us some feedback". My apologies for this delayed reply.

I went through all suggestions. As you said, I think, to invoke help system in VALID is not ideal. As Mike said, I will add another small button for invoking the help (with a '?' mark) near the textbox. Too, I think I can code for invoking the help (may be by calling the 'click' of that ? button) on the keypress of textbox for the F1 key. Let me try that.

Thank you very much.
So happy that all my discussions are going on great and learning a lot from mine as well other discussions.

Rajesh

 

[Rajesh Karunakaran]

Hi all,

But to make the F1 key to invoke my help list, I have to suppress F1 calling VFP help windows by issuing ON KEY LABEL F1 command at the startup, isn't it?

Rajesh

 

[Mike Lewis]

Rajesh,

Thanks for coming back with your feedback. I think the solution you have adopted should work well for you, but please let us know how you progress with it.

Regarding the use of F1, the point is that this is a standard way (across many applications) for calling a Help screen. In VFP, by default F1 invokes VFP's own Help file, which of course would make no sense to your users. So you would normally create your own custom Help file, then use the SET HELP command to establish it as the default for your app.

In your case, you have a particular Help screen that you want to invoke for a specific text box. The usual way of doing that would be to create a topic in your custom Help file and give it a specific topic ID. You then assign that same ID to the textbox's HelpContextID property. So, when the user hits F1 from within the texbox, the Help will open at the correct page.

The problem is that, if you did that for this specific textbox, you would really need to do it for all the editable controls across the application, each with their own help topics. Otherwise, that one textbox would be inconsistent with the others, which is not a good user experience.

The other problem, of course, is that you would have to go to all the trouble of creating a Help file (which is not trivial; I know because I have done it many times), even if you only wanted to use it with that one textbox.

For those reasons I suggest you forget about using F1 and simply let them click on the little button with the question mark on it. That would be completely intuitive.

You would write code in the Click event of that button to actually display the Help. If the Help is contained in a normal VFP form (which would be the simplest solution), then the Click event would simply contain [tt]DO FORM ....[/tt] If you decide to create a full Help file, the Click event would contain a command in the form [tt]HELP ID <topic ID>[/tt].

I hope this is helpful. The important point is not to suppress F1, but to provide a better alternative.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Dear Mike,

I think I would go with your suggestion of not using F1 for this particular purpose. Mr Olaf also was suggesting that.
By the way, by help list, I mean a selection list which is records of a master table.

Now, I thought of using F2 instead of F1 but my KeyPress event of the text box not firing.

LPARAMETERS nKeyCode, nShiftAltCtrl
IF nKeyCode = -1
	this.Parent.cmdVesselHelp.Click()
ENDIF

If I click on the button, it works.
As I found from help, I checked the KeyPreview of the form. It is .F., the default.

Rajesh

 

[Mike Lewis]

If you really want to give them a keypress to invoke the Help, you can do it by setting the caption of the button to something like [tt]\<Help[/tt]. The user will then be able to invoke the Help but hitting[tt] Alt+H[/tt]. Obviously, it doesn't have to be H. It's just the first letter of the caption that they hit.

If you don't want the button to show a caption, you can hide it, for example by setting the button's forecolor to the same as its backcolor, and then adjusting the PicturePosition and/or PictureSpacing properties so that the question-mark icon fills the button.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Rajesh Karunakaran]

Dear Mike,

Yes, I can do that. But, I am trying for the function key because my person is a bit particular about it as their old system had that thing and the users are used to it. Let me check which way would work good for them as well as me.

Thank you,
Rajesh

 

[Olaf Doschke]

I always understood you correctly about a list of values to pick from with your help list and not calling the CHM application documentatiotn/help text.

Anyway, While I don't see a reason to not use F2, the keypress of F2 doesn't work for me, too.

Use F5, perhaps. On many keyboards function keys are grouped. In mine F5 is easily found as first F-key of the second group.

Also note, like almost all keys F2 and any F keys have different keycodes with modifier keys pressed at the same time. Modifier keys are all the keys you also get a separate flag for in nShiftAltCtrl, but also nKeycode itself changes, when you press SHIFT+F2 or F2 with capslock instead of F2. So in a keypress even always check the correct combination of nKeyCode and nShiftAltCtrl, the latter should be 0. You don't want that to be different, beause as an example nKeycode 97 can mean "a" alone, or CTRL-F4.

Finally, the next pitfall is, you test the button, then press F2 (or F5) - the textbox doesn't have focus anymore, the focus doesn't only get to the button for the time of the click, it stays there. So perhaps in the button click set focus back to the textbox.

Bye, Olaf.

 

[Rajesh Karunakaran]

Yes Olaf,

F1 and F2 were not working. But other keys are triggering the keyPress it appears.

As I took of the help calling from the VALID, I was saved from the Close button issue. Now, when I click the button, it does its job.

Yes, I know about the different key values when key combinations are used. However, you have a point in checking the nShiftAltCtrl value always which I didn't think of.

Rajesh