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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calling SetFocus() from Valid event

Status
Not open for further replies.

sdocker

IS-IT--Management
Aug 12, 2010
218
GB
The code below is in the valid event of a ComboBox. I am calling SetFocus() and it should produce an error. It did once, so I took a screen shot of the message. Now when I come back to it, it works fine.

The ComboBos style is set to 2: DropDown List.

Code:
WITH THISFORM
	.REFRESH

	*-* According to the help file, this SHOULD produce eror # 2012. IT DOESN'T.
	.txtDescript.SETFOCUS()
ENDWITH

Not a serious problem. I just wold like to understand what I don't understand.

Sam
 
You're right. This should produce an error. But are you sure the Valid is firing? With a combo box, it only fires if the user actually changes the value AND attempts to leave the combo. And in fact the behaviour is slightly different depending on whether the Style property is 0 or 2.

Rather than calling Setfocus to change the focus, you can RETURN an object reference to the target control. In this case, that would be:

[tt]RETURN thisform.txtDescript[/tt]

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Well, not completely sure, but the help may only mean the restriction on THIS.Setfocus().
It's about not causing a loopback effect.

It's true though, that before you don't end the VALID event vfp does not know if setting focus elsewhere actually is allowed, you better RETURN THISFORM.txtDescript
Besides, as you always refresh and set a certain focus, think about simply using the tab order so the txtDescript is naturally the next control after this one is left.

Bye, Olaf.



 
Hi Guys,

I'm sure the valid event was firing.
I will use the object reference as Mike suggested.

Olaf,
Good suggestion, except using an object reference is easier than resetting the tab sequence.

Thanks
 
Well, there is a visual editor for tab order, quite easy to use. If the tab order is not at all correct even more so a reason to fix this, you're making keyboard affine users reject your application, if tabbing between controls seems to happen in no logical order and jumping around. The correct RETURN object should do anyway, but notice someone clicking at anything else also is surprised by this forced focus order. At least see what happens, if you eg click on some button, that would need to be prioritized before txtDescript, eg a record deletion button or cancel or exit button.

Bye, Olaf.
 
I have set the tabs, but this particular control has TabStop = 'N', so it is out of order, so to speak. If the ComboBox is changed, then txtDescript is the next logical control. If another control is moused, the valid event is not fired.

In any case, all seems to be working now.

Thanks.
 
Well, the valid event always runs. Event order is valid of old control, when of new control, lostfocus of old control, got focus of new control. There is no way to get out of some control without going through it's valid, otherwise there woul be no chance of a control keeping focus, wehn valid returns .F. or 0 or THIS.

Anyway, if you tested, this might be due to clicking a control moves focus two teims from combobox to description textbox to clicked control.

You may use Eventtracking set to record all events to see in which order which events run.

Bye, Olaf.
 
I just wold like to understand what I don't understand.

Nobody has addressed this.

During VALID(), VFP is deciding whether or not focus may leave the current control. Focus cannot leave until Valid() finishes its job.

Setfocus() attempts to move focus, which is not "up for grabs" until Valid() has ended.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top