Problem with focus and subform with no records 1

[ImpMan]

I have a main form with subform. A combo on the mainform is linked to the subform. Nothing complicated there. That works fine.

Also on the mainform is a text box. The contents of the text box are changed using the 'on change' event from the combo. This process only works when the subform returns records. When no records are returned an error is generated that states

'you can't reference a property or method for a control unless the control has the focus'

This occurs despite having explicitly given the focus to the textbox (in code) prior to trying to change its text.

I think the problem lies with the fact that the form expects to give focus to the subform but cannot because no records are returned, or something like that.

Please help!!!

 

[RickSpr]

Actually, I don't think the subform is your problem. I think it's that, during the combo box's Change event, you can't switch focus right away. Your SetFocus to the text box is accepted, but is deferred until you exit the Change event procedure.

This problem only seems to happen when you refer to a property of the control explicitly, such as "Me!txtLocation.Text". I find that I can avoid the error by coding it as just "Me!txtLocation". Or maybe it's "Me.txtLocation". Try both; I'll bet one will work.
Rick Sprague

 

[ImpMan]

Thanks for the reply. I have tried your suggestions. Unfortunately this still does not help. Either the boxes do not get any updated text, or the error appears.

Do you have any other ideas?

 

[RickSpr]

Sorry, I don't have any other ideas. This may be a behavior of Access I haven't run across before. I'd be interested in debugging it hands-on, if you'd like to send it to me. My email address is handlbar@broughton-sys.com. Is this Access 97 or 2000? Rick Sprague

 

[ImpMan]

I think I have sorted the problem.

1. The main form does not need to have a 'Record Source' due to the nature of the form so this can be left empty. However my record source was pointing to the place where my subform was looking for data (I don't think should be a problem although this was a mistake on my part).

2. The datasource for the subform (and also my main form) was a union (which by default does not allow additions).

3. The union was a product of queries that returned no records.

4. Then changing the combo and trying to reference a control in the on chnage event procedure produces the error.

The solution. Your mainform record source should not point to the same place as your subform record source if the source is a union. Come to think of it would you ever want your subform and mainform pointing to the same place??

 

[RickSpr]

: "...Come to think of it would you ever want your subform and mainform pointing to the same place??"

I can't think of a good reason to use a subform if all the data is available in the recordsource of the main form, so I'd have to say No!

I'm glad you found the solution. I'm curious, though. Since both the form and the subform were using the same record source, both of them must have had empty recordsets. Was the text box you were trying to update bound to a field? If so, I could see that generating an error, since there was no field to receive the value, but I wouldn't have expected it to be a "focus" error. Oh well! As long as you've got it working--smart folks don't mess with success! Rick Sprague

 

[RickSpr]

Ok, I've played with the database you emailed me, and I've got one answer. First of all, it is the problem I described in my first response. If you remove the ".Text" property name and just use "txtBaseEventDescription = stgdes", the focus problem goes away. (And you don't need the SetFocus statement any more.)

Going back, I see your answer to that was "Either the boxes do not get any updated text, or the error appears." Now I understand what you mean by "the boxes do not get any updated text"--but you're mistaken! If you perform the experiment with the database you sent me, after removing the ".Text", you'll see a big black rectangle in the second box. That rectangle is selected text, but you can't see the text because for some reason it's black text on a black background (or when not selected, white text on a white background). Why it's doing that I don't know!! But you can verify it--just copy the selection to the clipboard and paste it in Notepad (or even paste it back in the text box) and there's the word, big as life!

I'm going to keep trying to figure out why the text color is being messed up. Your properties are set correctly, so apparently it's a bug of some kind (in Access, I think, not in your code). We can probably find a workaround. But you're right--it was 2 problems. Rick Sprague

 

[RickSpr]

After more experimentation, I'm now convinced this is a bug in Access. In relational database theory, there is no difference between the results of a union query and a plain select query. Access, therefore, should not treat them any differently.

But as you've found, Access does treat them differently. If a form is based on a select query that returns no records, Access draws the detail section of a form normally, except that of course no field data is displayed in the controls. But when the form is based on a union query that returns no records, Access aborts the form drawing process. That means that even controls which are not bound and have valid data are not redrawn properly. That's a bug.

I searched the Knowledge Base using the keywords "union query" but didn't find anything even remotely like this problem. I also verified that it persists from Access 97 to Access 2000. Feel free to report this bug to Microsoft if you like. I'm quite sure it hasn't been reported before.

I found a workaround, too. If, after you set the text box value (remember, don't specify the Text property explicitly) you then "change" the text box's Fore Color to 0 (black), the control will be redrawn and the data will show.

I can deduce how some of the more subtle effects of this bug happen (such as the apparent "white on white" text, though in fact I can tell it's not really drawn at all), but it gets deep into some arcane knowledge of Access and Windows internals, and it probably doesn't matter to you anyway.

Well, that was fun! Hope the workaround gets you where you want. If not, ask back--maybe I can help some more. Rick Sprague

 

[ImpMan]

Thanks for your in-depth investigation of the problem.