DOEVENTS() does the trick 1

[craigsboyd]

I just had the weirdest thing happen in one of my programs...I had this form with a bunch of readonly controls on it and when the user clicks the New button it is suppose to do a few things and then set focus to the first textbox...well it kept setting focus to this combobox right under the text box...but when i debugged the problem was solved...so finally i put a doevents() into the code just before calling txtFirst.setfocus() and it worked...I guess VFP was getting ahead of itself and the combobox had already dropped its readonly status while the textbox hadn't yet...though their readonly properties were called chronologically txtFirst, cmbSecond and well before the setfocus..at least 1/100 of a milisecond anyways Anyone venture a guess as to why? Multiple threads maybe? Some type of message Queue switch-a-roo? Slighthaze = NULL

 

[ramani]

HI

Your tabing order is not the order in which the init or such events are taking place in a form. Quite often we assume that first tab positioned control fires its init first. NO... definteltly not in that way. The objects are created in the order we craeted them. In all probablity, the combo box was the first one you created, even befoore that textBox in that form. I have faced this often and all the more reason that I make each control self reliant as far as possible without trying to take the value from another in its init events. Such dependencies should be valued in the refresh event at form level or in the init of form, so that all other objects are initiated by that time.

ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[ramani]

Hi

May be you are using some ActiveX control in your form. Check on AutoYield property in the Help. May be this is more specific to your issue.
ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[craigsboyd]

that's a good point about instantiation order but if my order of code after the user clicks the NEW button is this...


...do some code not dealing with the controls and then...
txtFirst.readonly = .f.
cmbSecond.readonly = .f.
txtFirst.setfocus

Why would it send the focus to the combobox? Shouldn't it already have set the readonly property of txtFirst to .f. by the time it gets to the setfocus() call? What would the order in which the controls were instantiated have to do with that? Why would debugmode not show the same problem...and why would...

txtFirst.readonly = .f.
cmbSecond.readonly = .f.
DOEVENTS()
txtFirst.setfocus

...fix the problem?
Slighthaze = NULL

 

[craigsboyd]

that's a good point about instantiation order but if my order of code after the user clicks the NEW button is this...


...do some code not dealing with the controls and then...
txtFirst.readonly = .f.
cmbSecond.readonly = .f.
txtFirst.setfocus

Why would it send the focus to the combobox? Shouldn't it already have set the readonly property of txtFirst to .f. by the time it gets to the setfocus() call? What would the order in which the controls were instantiated have to do with that? Why would debugmode not show the same problem...and why would...

txtFirst.readonly = .f.
cmbSecond.readonly = .f.
DOEVENTS()
txtFirst.setfocus

...fix the problem? I thought messages in Windows OS were FIFO. The combo is getting readonly set to .f., the txtfirst.setfocus is getting done, and then after that txtFirst is getting readonly set to .f. so that when you look at the form there the focus is in the combobox though it should be in txtFirst by all accounts, shouldn't need a doevents() to get it there is what i'm thinking.
Slighthaze = NULL

 

[craigsboyd]

you get a star RAMANI, that's exactly what is happening...nice job and thanks for the second suggestion, it was right on the money...disregard my previous post or should i say post(s) since i seem to have submitted it somehow before i was done writing it. Slighthaze = NULL