As I bet I can tell the following is happening in my Excel 2013 macro:
Sub WorkSheet_BeforeDoubleClick is calling a form
Some logic populates and shows the form
The double click event is captured by the form as an undesired selection in a listbox
Is there a correct way to suppress the double click in the middle of the subroutine? I have ideas for getting around it (sleeping the thread works, re-positioning the form works, locking and unlocking the listbox based on other events works) Those are all poor workarounds and I am hoping for a built-in solution that I am just not aware of.
(And setting Cancel = True does not work because I believe setting only kicks in once the code is finished running. The double click becomes a selection in the middle of the subroutines)
If the issue is the form you are launching from the macro is catching the same double click event try the following:
1) Have your macro call a new sub routine via 'Application.OnTime()' schedule it to run just long enough in the future to pass the 'physical click', maybe 1s. Instead of directly calling Form.Show(), as you are currently doing.
2) Your new subroutine just has to do: Form.Show(), and whatever else you deem necessary.
Related
Is it possible to use the call feature to call a macro at a specific line? I ask as the macro i am coding does this - First it runs half of the code, then based upon user choices it opens up a custom UserForm, and runs the UserForm command buttons. After this I need a command button to go back to the code the line after the UserForm was used. The UserForm works as intended and many different stats calculations can be run. It has a button that returns the user back to the rest of the code, but I can't get that to work.
I have tried using both GoTo statements and the Call feature (The most promising solution) but have had no success so far.
There are several ways to achieve it, I will show one of them.
You can modify your procedure (macro) asking for a value as optional.
Sub MyMacro(Optional Answer As Boolean)
If Answer = True then
'Do some stuff
Else
'Do some stuff
End If
End Sub
As Answer is optional you can call your Macro with or without arguments.
Suppose you call your Macro from your user form:
Call MyMacro(True)
Hope this give you some hints.
You can use VBA for this, but I would recommend using the Windows Task Scheduler. I think that will be a lot better, all things considered.
https://www.digitalcitizen.life/how-create-task-basic-task-wizard
If you have look at these two captured images...
Basically, stepping into the next line should not change the selected tab as shown here. This is what happens if I click F5 from the VBA Editor to execute the sub
But when I actually run it using a linked command button which suppose to be doing the exactly same thing (photo shown down the thread). but what happens is this,
Stepping into the next line actually somehow changes the tab!
There is noting in the first break point line that tells excel to select another tab... why is this doing this.
if I run it using F8, actually this problems goes away.
UPDATED=============================================================
I come across some weird behaviour in the Excel VBA and can't explain why its doing it.
Sub run_simulation()
ActiveWorkbook.Worksheets("Run Simulation").Select
ActiveSheet.CommandButton1.value = True
End Sub
This subroutine selects a sheets then simulates the clicking of a button 'CommandButton1'.
When I execute this from the play icon within the VBA Editor it runs fine but when I run this 'run_simulation' subroutine from a linked button on another sheet... like this
an error returns saying that the selected sheet "run_simulation" is protected and needs to be unprotected before proceeding... the thing is it unprotects the sheets automatically when the commandButton1 is clicked.
The Worksheet.Protect method has a little-used UserInterfaceOnly parameter.
From MSDN:
UserInterfaceOnly (optional) - True to protect the user interface, but not macros. If this argument is omitted, protection applies both to macros and to the user interface.
Set this to True when setting the worksheet protection and you will be able to manipulate the worksheet objects programmatically.
This is a distilled form of a problem I'm having with a real application. Under certain circumstances, the initialization/activation code of a userform might result in the form losing its ability to correctly process tabs and enters: rather than switching between controls, these keys are passed to the controls themselves (even if they have TabKeyBehavior set to False). The simplest way I've found to systematically reproduce the problem is by having this at activation time:
Private Sub Userform_Activate()
Application.DisplayDocumentInformationPanel = True
End Sub
which seemingly causes Excel to "half-steal" the focus from the userform, so to say: the userform remains focused but tab/enter processing fails. The problem immediately goes away by switching to some external app and getting back to Excel (pressing ALT+TAB twice, for instance.)
Steps to reproduce the problem:
Download tabnotworking.xlsm.
Open tabnotworking.xslm.
Enable macros.
Click on the "Launch UserForm1" button.
UserForm1 is displayed and the textboxes accept input from the user, but tab/enter does not work as expected.
Press ALT+TAB twice or click on some external app and get back to the form: now tab processing works OK.
Once tab/enter processing has been restored, further usage of the form, including relaunching it, seems to work OK (most of the time). To reliably reproduce the problem again, close the book and start from step 2.
There are numerous references on the Internet to problems with tab processing seemingly related to this one, but no actual solution. Any clue on what's happening and how it could be solved? Thank you,
so basically I need to pause the macro code, wait for user input and then continue the rest of the code. I know that by using the "modeless userform", this can be done.
But the point now is that all the code after the userform popped up needed to written in the command button part (basically it is the userform own module). And because of that, all the initialization, all the variables that I still need has been wiped off.
So I am asking is there a way to pause in the middle of a vba code then, wait for user input, then continue the rest of the code
Thank you very much for your help
What do you mean as "user input"?
Standard input methods as MsgBox, InputBox or modal user forms do what you are asking;
"code after the userform popped up needed to"...
Instead of closing a form, hide it. Code continues and form data
still available;
Now, if you mean by "user input", manipulating workbook, you must go on events:
Example: Create a before user input macro and then place remaining code in a Worksheet_Change event.
Needing some help attaching an Excel/VBA button on an Excel sheet. I need it to stay in the same position on the screen regardless of how I scroll or zoom. Preferably, I need this on the bottom left or right of the screen.
I have tried adding a button. Then, I right clicked on the button. Clicked on Format Controls -> Properties -> selected Don't Move or Size With Cells. Am I missing something that's making this not work?
Thanks!
I know this post is old, but here's to anyone it could be useful. The VisibleRange property of ActiveWindow can solve this problem. Use something like this:
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
With ActiveSheet.OLEObjects("MY_BUTTON'S_NAME")
.Top = ActiveWindow.VisibleRange.Top + ActiveWindow.VisibleRange.Height - 5
.Left = ActiveWindow.VisibleRange.Left + ActiveWindow.VisibleRange.Width - .Width - 5
End With
End Sub
Here is the idea that I put across the comment earlier today :) Typically we can get a Floating User Form by setting the Modal property of the form to be 0 which is indeed a Modeless state.
Basic Points to consider:
Look & Feel of the form to make it look like a Button (Not show title bar/Not Resizable/
Hidden Close Button etc)
Setting the position of the Button
Which Event should trigger the form-button (WorkBook Open)
What would you do with Form Initialize Event
Whcih Events should keep it stick to the same position alive
Further Points to consider:
You might only want to keep this button vissible for the workbook you are working, and if you open another instance of a workbook, do you still want to keep the button
If you minimize the Excel Window instance, how do you plan to manage the state of the button and keep it visible
Post about keep displaying a form even the workbook is minimized.
One other great reference I happend to see, (little bit technical) but worth the shot - at least to get to know the certain properties/methods that you could make use: Extending VBA User Form Control.
The article include the following info, and please note the last line as well :)
They give you access to capabilities that are not available from VBA or from the objects (UserForms, Workbooks, etc.,) that make up a VBA Project. When you call an API, you are bypassing VBA and calling directly upon Windows. This means that you do not get the safety mechanisms such as type checking that VBA normally provides. If you pass an invalid value to an API or (a very common mistake) use a ByRef parameter instead of a ByVal parameter, you will most likely completely and immediately crash Excel and you will lose all your unsaved work. I recommend that until you are confident that your API calls are solid you save your work before calling an API function.
Add new Row on the beginning of your WorkSheet and set your button on it, then:
Freeze Top Row
Right click → properties → placement → change to 3.