Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Keep object focus
Message
From
09/03/2000 10:48:22
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00343116
Message ID:
00343682
Views:
25
>>>Aston, move your Setfocus() code from Valid() to LostFocus() and it will work.
>>>
>>Nick,
>>
>>SetFocus from a LostFocus will only work if you also include a NODEFAULT after the SetFocus call. Otherwise the dafualt behavior fo the LostFocus will move focus to the next control after your SetFocus has done what it is doing.
>
>Hi Jim,
>
>I know about this point and did so before, but since awhile I found that NODEFAULT is not necessary here.
>
>If we make a simple test:
>
>Create a form,
>Drop 5 textboxes on the form.
>In text4.LostFocus() put
>
>this.parent.text2.SetFocus()
>
>In my tests this works identically to
>
>* text4.LostFocus()
>this.parent.text1.SetFocus()
>NODEFAULT
>
>and NODEFAULT presence seems to have no effect on successful SetFocus to text2 textbox, no matter if you use Tab, Enter, clicking on another control or pressing Esc in order to leave the text4 textbox. I tested in VFP 3, 5, and 6 and it all worked the same for me. I also tried with adding the button with .Cancel = .t. and the button with .Default = .t.
>
>The only case found when SetFocus was not set, is when you are tracing the code in the Debugger and have some code immediately after the line
>
>this.parent.text1.Setfocus()
>myVar1 = 0
>myVar2 = 1
>
>In this case the focus goes to the next control and adding NODEFAULT also has no effect on this behaviour.
>
>If we are not tracing the code - Setfocus() from LostFocus() works fine, and the code after SetFocus line is executed too.
>
>So, my point is that NODEFAULT is not necessary when you are trying to SetFocus from the LostFocus() event.
>
>I would be glad to hear your thoughts about that.
>
>Nick


Agree Nick.
NoDefault is not needed unless you really want not to dodefault(). If the focus would stay on current control then it's where you shouldn't dodefault() (and use nodefault).
*Lostfocus
if !lSomeValidationPassed
   nodefault
   this.SetFocus() && To activate gotfocus and cause selectonentry etc work
else
   thisform.GoToThisControl.Setfocus()
endif
Actually as I could see a dodefault() in a builtin method causes the method "dodefault" twice (this could be observed nicely in keypress and do not try to do in grid.control.gotfocus where already it's buggy and fires twice:). There is a special case where I might want to use dodefault() in lostfocus. That is to move focus to nowhere :)
*Lostfocus
*thisform.SomeOtherControl.Setfocus()
if type("thisform.ActiveControl")="O"
  wait window "Before dodefault :"+thisform.ActiveControl.Name timeout 2
else
  wait window "Before dodefault : No active control" timeout 2
endif
dodefault()
*thisform.SomeOtherControl.Setfocus()
if type("thisform.ActiveControl")="O"
  wait window "After dodefault :"+thisform.ActiveControl.Name timeout 2
else
  wait window "After dodefault : No active control" timeout 2
endif
*thisform.SomeOtherControl.Setfocus()
Try with uncommenting various setfocus + commenting dodefault().

PS:For the original question doing validation in lostfocus and having nodefault is my personal preference to valid - return 0 or .f. That way I can control the messages more flexibly + go somewhere else and come back :) If I do that in valid another setfocus() in another code piece might catch me badly. Of course there are places where I cannot do w/o valid too :)

Cetin
Çetin Basöz

The way to Go
Flutter - For mobile, web and desktop.
World's most advanced open source relational database.
.Net for foxheads - Blog (main)
FoxSharp - Blog (mirror)
Welcome to FoxyClasses

LinqPad - C#,VB,F#,SQL,eSQL ... scratchpad
Previous
Reply
Map
View

Click here to load this message in the networking platform