Working in both A2003 & A2007.
How do we ensure that a selected TextBox gets the focus when the form loads? If we put MyTextBox.SetFocus in the Form_Load then we get the error:
can't move the focus to the control
This form is designed for rapid data entry, and the form somewhat rearranges itself based on the last used settings. So there are several different textboxes any of which may need the focus depending on the user. We can't just fix it in design time by giving MyTextBox TabIndex=0.
The help says something about calling Repaint which just doesn't make any sense at all:
You can move the focus only to a
visible control or form. A form and
controls on a form aren't visible
until the form's Load event has
finished. Therefore, if you use the
SetFocus method in a form's Load event
to move the focus to that form, you
must use the Repaint method before the
SetFocus method.
The best bet in this case, is to ensure that the textbox to get focus is numbered 0 in the Tab Index property.
You cant set the focus as the controls don’t really exist yet, try putting the code in the OnActivate event instead
Or just put a DoCmd.Repaint in the OnLoad event before trying to set the focus. Both should work but I'm not near a computer to check
In my experience, I've always gotten that error when the control I was trying to set focus to was either 1)not visible or 2)not enabled. I assume you've already checked those, but it would be worth double checking at runtime when you get the error message (especially since you said you are shuffling the controls at runtime).
I use the .SetFocus method pretty regularly without trouble. I don't recall ever getting an error message when setting focus to a control that already has it as Remou stated in his answer.
I believe there is also a third case that occurs if you try to set focus to a control in the form header/footer of a bound form that has had all of its records filtered out. I know that situation causes "disappearing" contents in an unbound combo box, but I think it may also play havoc with the SetFocus method. If you are opening the form in Data Entry mode, though, that should not be an issue.
Move SetFocus to the form's On Current event. Should work then unless perhaps the form's record source contains no records and you've set the form's Allow Additions property to No. In that case your text box will not be available to SetFocus on, but in my testing it doesn't throw an error.
Related
I have a form with several subforms whose content is edited in separate forms, opened by command buttons.
When the data in those forms is updated, and the extra forms closed, naturally the main form needs to be refreshed before those changes can be seen. Clicking the Refresh All quick access toolbar button achieves this perfectly.
So I made a macro for the "got focus" event on the main form to refresh it, but it does nothing. I tried repaint and requery as well, applying the latter specifically to the subforms in question, and ran them out of vba instead of an access interface built macro too, none of these seem to solve the problem.
vba coding:
Private Sub Form_GotFocus()
Screen.ActiveForm.Requery
Screen.ActiveForm.Repaint
Screen.ActiveForm.Refresh
Me.sfmContact.Requery
Me.frmCustCert.Requery
Me.frmCustReq.Requery
End Sub
Annoying thing is that if I put this (or even just the macro or Screen.ActiveForm.Refresh) in the on click event of one of the controls it works fine. Just can't seem to make it work in any automatic events that don't require thought or clicks from the end user.
This question is sort of a dupe of Refresh button on an Access form but that question is over a year old, and has no accepted answer. So I've expanded on it.
What you mentioned in your comment there is correct:
My guess is that it's not running it, but I don't know why. I got mixed up between OnActivate and OnLoad, which is why I didn't try that option. That works and solves the problem, but why wouldn't GotFocus fire? Surely the main form lost focus when another form got it for updating, and then it got it back again when the other form closed/anything in the main form was selected...
To avoid this type of error in the future, it may be prudent to specifically name the form in your code instead of using the "Me." command, as that only works for current focus. For instance:
Me.sfmContact.Requery > Forms![FormName].sfmContact.Requery
Alternatively, you could just set the focus to the form in question before that sort of coding.
Forms![FormName].SetFocus
I think I'm looking directly at an Access 2003 bug. Here's what I did (I think):
I'm developing a Continuous Form (i.e. multiple records per page).
I have an unbound textbox in the background of the Details section. Under Data Properties, I have Enabled=No and Locked=Yes. (In other words, I don't want the user to select it. I only want it for the background color)
This textbox also has some conditional formatting to change the background color for that row. (e.g. If we haven't spoken to that customer in awhile, the background for that record is red)
If I choose a record where the conditional formatting is active (i.e. the background is red), I can actually click on this textbox. There's not much that I can do, of course, but this shouldn't happen and surely would be confusing to the end-users.
Has anyone else seen this? What's your workaround?
Enabled is a property that can be controlled via conditional formatting. By default when you add a new condition, the Enabled property is set to True. If you don't want your control to be enabled you must explicitly set Enabled = False within the conditional formatting rule.
The property is toggled via a button in the lower right corner of the conditional formatting dialog. It's easy to miss (I forget about it all the time).
Personally, I think the property should be three-way: True, False, or Inherit (with Inherit as the default). Unfortunately, Access forces you to be explicit when adding conditional formatting rules and state whether the rule should make the control Enabled or Disabled.
Here's my workaround (I was waiting to see if anyone else would suggest something better. Apparently not.)
In my conditionally formatted textbox, add an Event Procedure for GotFocus. Enter this code: Me.Txt_FocusHere.SetFocus.
Make a 2nd unbound text box somewhere on the form. Shrink it until it's just 1 line thick. Call it Txt_FocusHere.
So whenever the user clicks on the colored background, the focus is immediately taken to this dummy textbox which can't store any data and is so small that the user doesn't see the blinking cursor.
I successfully used the method on the following page: http://www.mvps.org/access/forms/frm0047.htm - "Changing the Background Color of the Current Record in a Continuous Form"
I'm designing a Form in Access 2003. My goal is that when the user double-clicks on a record (aka Detail), a second form opens. This is easy enough to do when I start from scratch.
But of course, I'm not starting from scratch. I've been working on this for a few hours now, have added some conditionally formatted textboxes, fields, etc, and don't want to start over if I can avoid it.
I don't know if I turned on/off some obscure property, but I've been working on this form for a few hours now and the Double-Click event of the Details section only triggers when I double-click on the first record or any other with conditional formatting.
To troubleshoot this, I've gone so far as to comment out all the other VBA script except this:
Private Sub Form_Load()
Me.Application.DoCmd.Maximize
End Sub
Sub GotoFrmDetails()
MsgBox "You Double Clicked Me!"
End Sub
Even with the VBA script reduced to just these lines, the DoubleClick event only triggers on the first record and no other. Can anyone tell me what wrong? I'd rather not have to rebuild this from scratch.
I find the click events of form sections to be more trouble than they are worth (click event doesn't pass through to the form if user clicks on a control or label, etc). What I use instead are transparent command buttons.
Just add a command button to your form and set its Transparent property equal to True. Then you can use the Z-order to make fine-grain changes if necessary (send to front/back, send forward/back).
They can be hard to find once you make them transparent, so be sure to give them descriptive names.
If you want the user to be able to double click anywhere in the detail section, just make the transparent command button's height/width match the section height/width.
Move your code from the Detail section DoubleClick event to the transparent command button's DoubleClick event and you should be good to go.
I'm wondering if the rows are getting their Locked property set to Yes, or their Enabled property set to No during your condition formatting.
I have multiple combo and option boxes whose visibility is set true or false depending on user selection of other parent option boxes.
I am using the AfterUpdate() function for the parent option boxes. This method has been working fine.
However when I set the values of the option boxes in VBA code (Me.MyOptionBox = 1), there is no "update" to make the child option and combo boxes appear. It works when I manually click on the option, but if I set it in the code nothing changes except for the option box selection. It doesn't make sense to see the option box set correctly but the code responsible for checking which option is selected not work.
Does anyone have any ideas on how to get around this? I just want the form to be updated once I set the values of the option boxes. What is the "update" that AfterUpdate() is referring to anyway?
I have tried MyForm.Repaint and MyForm.Requery but these do not work either.
Any ideas?
You can call the OptionBox_AfterUpdate() method directly - after you set the values.
I'm pretty sure this is intentional. The problem is avoiding circular recursive updates, when you consider that a control can be changed by a user and by two forms of code (explicit and bound data).
For bound controls, changes in the data change the controls.
For user input, changes in the control change the data, plus whatever dependendencies you explicitly specify in events.
For changes caused by your code, the assumption is that you need to manually apply all the consequences of the state change you are coding.
If you are using bound controls, you can change the datasource and have the consequences applied automatically.
In VBA, most control events do not fire when the control is updated programmatically, rather than manually. You must specify the code that is to run after the programmatic update.
By "I am using the AfterUpdate() function," you mean you added an event handler for the AfterUpdate event, right?
If that handler is not firing when you expect it to, you could always call your handler directly (instead of letting the event fire it) where necessary. But that probably wouldn't be the best way of doing it; more likely there is another event that should be calling your handler instead of or in addition to AfterUpdate. I don't remember the names of combo box events, but isn't there something like ItemChanged or SelectionChanged or something?
I have a series of "on Change" Enabled/Disabled subroutines in the VBA for a form.
When scrolling through the form to view records however, only the main routine runs--the subroutines don't. As a result, questions appear disbaled that have responses displayed.
How do I get the subroutines to run when a record is viewed/changed?
The OnChange only fires when the relevant object is updated. If you want code to run whenever the record is scrolled, put it in the form's OnCurrent event.
I too have found Access form events to be a bit hard to work with/unpredictable. One thing that worked for me is to use a label or textbox and set the Control Source to a formula or a call to my own VBA function to get what I need done. Your control could also be invisible if it is not needed for the GUI. I doubt this is best practice but this "simulated" event worked for me.
If you need conditional presentation in a list, a continuous form and events are not going to do the job. In some cases CONDITIONAL FORMATTING will do the job, but only for appearance -- it can't do things like show/hide controls or alter the rowsource of dropdown lists or requery them.
Conceptually it would be impossible to do so. Form-level events fire for the record. Scrolling through the form does not move the record pointer.
I avoid using continuous forms for editing precisely because of this issue. Instead, I bind a detail subform to the PK value of the record selected in the continuous form, and then the detail form can do all the conditional formatting it needs to.