I realized while I was typing up this question what the problem might be and was then able to solve it. So, I have posted the question and then the answer in case it helps someone else.
I am using MS Access 2016. I have a Form_A that displays a menu of buttons--each button takes the user to a distinct form to perform whatever functions the user needs to perform. For example, one Form_A menu button could be [Add Clients] while another button could be [Add Staff], etc.
When the user first logs into the system, I use VBA code to do a number of "housecleaning" functions. Form_A and the buttons are visible, but I have made a Form_B that is a small dialog that shows the word "Working" with animated "..." while the VBA in Form_A does the housecleaning.
The problem that I cannot solve is that even though I have set Form_B's "Pop Up" property to "Yes" and its "Modal" property to "Yes", the user can still click buttons on the Form_A menu which then execute while Form_B is still doing its housecleaning.
I thought setting Form_B to modal should prevent button clicks on Form_A from getting registered.
More details:
In the Form_Load event, Form_A calls "housekeeping" code that resides in a Module. That module has a Public Sub called "RemakeTables." The RemakeTables code uses DoCmd.OpenForm "Form_B" to display the "Working" dialog.
The RemakeTables code calls several other Public subs. Between each call to the other Public subs, a DoEvents is called which allows for the "Working" dialog to animate the "..." (i.e., cycle between "Working", "Working.", "Working..", and "Working...").
My hunch is that the DoEvents is what is allowing clicks to get registered in Form_A.
How should I be doing this so that clicks cannot be registered while the Form_B "Working" dialog is showing but can still be animated?
As I was typing up the question, it occurred to me that the main problem was that the subs and functions I was calling during "housekeeping" used the DoEvents action to allow the Form_B "Working" dialog to update/animate. However, DoEvents also allows mouse clicks to register.
So, how to prevent the problem?
Include the "housekeeping" calls in the Form_Open event rather than the Form_Load event because the Form_Open event occurs first, before the Form_Load and before the form is displayed, so, there will not be any buttons visible to click if the "housekeeping" code is called in Form_Open.
Hope this helps someone else who might have had a similar problem.
Related
I have a form that opens a modal pop up helper form to collect some data. When this modal pop up form closes, focus returns to the main form. I would like to trigger some activity when focus comes back to my main form.
The event model for the form does not trigger the Form_Activate or Form_GotFocus events when returning from a model popup as per Microsoft documentation.
These forms and all controls are completely unbound.
Is there a trick to knowing in code when focus returns to my form?
If both forms are placed in normal mode, Form_Activate does fire in the primary form when the helper form closes, but this does not meet my needs. I have not been able to find a similar event to trap this. I'm hoping someone has a workaround.
For clarity, the issue I ran into was I had the design time properties in the helper form set to act as a dialog - (pop up and modal as true). When I opened the form responding to the button click event on the main form, I did NOT include the acDialog option.
If you omit the WindowMode=acDialog setting the code operates asynchronously completing the code in the click event handler in full, NOT halting and waiting.
The acDialog option apparently forces the DoCmd.OpenForm command to run synchronously, halting code execution, then returning once the modal form has been closed.
Private Sub btnHelper_Click()
DoCmd.OpenForm "frmHelper", WindowMode:=acDialog
'Do stuff after frmHelper closes
End Sub
I defined a form which I show as a dialog as per myForm.ShowDialog. The form sets the AcceptButton property correctly to my button. When I call the Close() method, the dialog result is always Cancel.
I searched about this issue and found this question where they suggest to manually set DialogResult when it should be different to Cancel.
Since VB.net offers me to set an "Accept" button I find this "solution" quite hackish though. The documentation for the AcceptButton property says that it determines which button is "clicked" when the user presses the Enter key. I also expected that would automatically set the DialogResult to "OK" but it does not seem to do so.
So, is manually figuring out which button was clicked and updating the DialogResult, which looks like cleaning up after the Microsoft guys who designed Windows Forms, the way to go or did I miss something?
The AcceptButton does not close the form automatically. This is because it is just the default button which gets "clicked" if you press Return. If you set the DialogResult in the buttons click event handler, the form gets closed directly so you don't need to call .Close() anymore, so this seems not to be a bug to me.
Working with the RadDesktopAlert WinForms component by Telerik, I am wondering how can I perform an action when the user clicks anywhere on the alert window.
To put it blunt, the buttons suck, and it is much more natural (easier) for a user to just click anywhere in the window. I checked the basics, and there doesn't appear to be an event for "Click", nor does it appear to expose it's Hwnd or Handle.
The events that are available are
Closed
Closing
Disposed
Disposing
Opened
Opening
PropertyChanged
RadPropertyChanged
RadPropertyChanging
The problem with the buttons is the UI looks wacky when trying to right-align, and the "click" event doesn't fire unless you click well inside the button - TWICE. So using the Buttons are not an option. What I am looking for is a place to write code that runs when the user clicks anywhere on the RadDesktopAlert box.
Thanks in advance.
The RadDesktopAlert component, has a Popup property, which holds the actual popup element. You can use its Click event for the purpose:
AddHandler radDesktopAlert1.Popup.Click, AddressOf Popup_Click
I'm building on top of code that a previous developer has left me, and he left something that intrigued me quite a bit.
Basically on his menus, he has a TextBox to take in user input and a button next to it to submit the value of the TextBox (for example if the user wanted to select option 1, he would input 1 into the TextBox and click the button). However, the user could also press the Enter key while focusing the TextBox, and it would be treated as the submit button was clicked.
Now this is simple enough to do, but when I check the VB code behind the menu, there's no TextBox_Keydown(...) Handles TextBox.Keydown function anywhere, only the button click event. How is he doing this? He has several menus that are similar and I can't figure out how.
A standard dialog box, if not told to act otherwise, enter does default command button and escape does cancel. In VB look at the properties Default for the command button.
I discovered how he was doing it. He basically mapped the AcceptButton and CancelButton properties of the entire Windows Form to various button functions.
I've got two forms, one being frmMain and the other being frmDatasets. The idea is that frmDatasets is used to manage the application's datasets (it's a program for comparing sorting algorithms).
I have a MenuStrip on frmDatasets with a few items. I just decided to change the Add Dataset item to a drop-down menu with options for loading one from file, or generating one according to certain parameters. All well and good; just add the items, swap some icons around, and change the event handler's signature to handle the right Click event.
Except when I run the program, clicking on the Add Datasets top-level item for the first time sends frmDatasets to the back, displaying an inactive frmMain. Clicking the item again shows the dropdown menu as usual.
If I instead click another top-level menu item, that works just fine. But then simply hovering my mouse over the Add Dataset item causes the 'send to back' thing to happen.
I say "send to back", but it's really just putting it behind frmMain. It remains in front of other windows like Visual Studio and Firefox.
Anyone know what on Earth is going on with this form?
EDIT: If I show frmDatasets as a modal dialog, it stops the whole "sending to back" thing, but I still have to click the menu item twice before it shows the list.
EDIT2: Overriding the onClick event to call mnuAddDatasetDropDown.ShowDropDown removes the double-click issue, but it's only a solution if I keep the form as a modal dialog. Still gets sent to back. Overriding mouseEnter doesn't do anything to solve it.
Setting the TopMost property of frmDatasets from its Design view to 'true' fixed all of the problems I was having. No insight as to what was going on, unfortunately, but if anyone else is having this problem then hopefully it'll work for them too.