The OP is using the header of the form to iterate controls. So the possibility of a label is high. Only thing is the OP states it works sometimes and not other times. I did not think labels were in the same group type as acTextBox?
The OP is using the header of the form to iterate controls. So the possibility of a label is high. Only thing is the OP states it works sometimes and not other times. I did not think labels were in the same group type as acTextBox?
that's why I suggested the debug.print ctl.name before trying to do anything with the control. I haven't tested it to know for sure if it's capturing a control it shouldn't even be considering, the debug.print should tell him that rather than guessing as I don't see any code to tell him which control is actually causing the problem.
As suggested in my instructions, could make copy and remove confidential data.
How to attach file: http://www.accessforums.net/showthread.php?t=70301 To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression.
I've set up an identical scenario, including an independent Label in the header, and your code runs perfectly, without problems! Although we usually think of Forms, or even entire Databases, when we speak of corruption, individual Controls can and do become corrupted. The test and the fix are one and the same; deleting the Control then re-creating it! I'd do that to the errant Control, first, and then to the Command Button, if need be.
Linq ;0)>
How is there any possibility of the label, since the code correctly restricts to textboxes and comboboxes?? There isn't ...
I don't think this has anything to do with labels.
This is one of those threads where, we can suggest random thoughts all week long, but .... Until the OP learns to do some debugging by onesself, it's basically just shooting darts in the dark.