Search results

Do you mean, even when the subform isn't displaying any records? Or do you mean it's surprising because the subform doesn't have the focus?

That should be If List13.Selected(i) Then

I have a memory that back in 2003 or whenever it was, I did submit this as a bug using whatever facility was around then, but what happened subsequent to that I honestly can't remember. The fact that no-one here seemed to know of the problem already despite it existing for more than 15 years...

As I mentioned in the original post, the problem I'm really trying to solve (as opposed to the bug I'm trying to work-around) is to reduce the number of entries in the combo box by doing something akin to Allen Browne's "Combos with Tens of Thousands of Records" code. The only way I can...

I can't see cascading combos working in this context partly because I'm not sure there's a natural way to break up the data. I suppose I could have separate input combo boxes for forename and surname... As I mentioned above, the performance of Allen's code seems fine (though I'm starting with...

There's definitely a "bug" there if only because it's putting out an incorrect message - because the control does actually have the focus. So even if there is a good reason for the situation being in place, it's telling you something that's factually incorrect about the problem and its potential...

Simply because the application is used by multiple people simultaneously (or potentially so) and can be used anywhere, where there may be no connection to the outside world. But the merging of data is all done manually (by which I mean in code rather than via any automated replication process)...

That's interesting, I'd always assumed that WHERE False was marginally quicker than something like WHERE 1=0 because it wasn't having to evaluate a condition but merely checking a boolean value. That's useful to know.

Yes, the value property is no problem, but it doesn't return the same thing as the Text property and in the particular instance I'm talking about I need to trap what's being typed in rather than look at the resulting value once the combo value has been updated. As I mentioned above, I'm looking...

I'm not, but there is good reason.

No, you're mistaken. The Value property relates to the bound field, the Text property to the displayed value. Similarly, properties like SelText (which also fails in the same way and under the same circumstances as Text), SelLength, SelStart relate to the typed/displayed value and not the bound...

No, the form's record source is "SELECT * FROM tblPersonX WHERE False;" There's a table here tblPersonX and False is an Access constant (so's True) so "WHERE False" is just a shortcut (for demonstration purposes) to produce no records.

I'm accessing the control from within the subform itself, so to my code it's a local control. I haven't got some long-winded Forms!frmSuchAndSuch.sbfrmSoAndSo.Form.cboCombo type construction, the controls can be accessed via Me.Name.Property.

Sorry, I missed this one But I'm in the Change event for that very control, it already has the focus. If you don't believe me stick "Debug.Print Screen.ActiveControl.Name" above the existing Debug.Print statement. Edit: That's odd. The forum software told me my previous comment had to be...

The example form's record source is "SELECT * FROM tblPersonX WHERE False;". Why would there be a table called 'False'? There's a table called tblPersonX, False (like True) is an in-built Access constant and "WHERE False" is a very standard construction to return no records in a query. This...

Let's face it, there aren't many forms in this world, especially continuous ones, where the data isn't filtered in some way. In my particular case, the original form having the error is a subform and so the records displayed there are determined by the master-child relationship it has with a...

As requested, here's a stripped down database. Just open form frmPersonComboTest and try typing into the ComboBox. The Change event in the ComboBox in the footer is set to debug.print the combo's .Text value, so if you type into the combo box it will either do that (if, miraculously, it works...

Must admit, I'd not tried it in Datasheet mode.

The form has to be bound to a query or table, if it's unbound then the problem doesn't occur. The error occurs whether the form is Single Record or Continuous and whether the form is used as a main form or a subform. The other thing is that because I'm using controls in the footer to input data...

For a long while there's been a bug in Access whereby the Text property of a ComboBox or TextBox control is inaccessible, even when the control in question currently has the focus, if the control is in the form footer (or header too, I think) and the detail part of the form is currently...