This article about
"Using events with the Application object" states:
Before you can use events with the Application object, you must create a class module and declare an object of type Application with events.
In my workbook in ThisWorkbooks module I have the following code
Option Explicit
Private WithEvents App As Excel.Application
Private Sub Workbook_Open()
Set App = Application
End Sub
Private Sub App_SomeEvent()
'This event fires without problems
End Sub
There is no problem with the code, as far as I have tested. However the above mentioned article made me think:
I know ThisWorkbook is a class module, same as sheet modules, but can I actually use them for this purpose?
Is there anything I have to keep in mind when not creating a new class module, or is the article wrong in that I have to create a class module?
It is absolutely possible to let ThisWorkbook module handle Application events.
What you need to keep in mind, if ever, is it violates single responsibility principle. Handling Application events is not the responsibility of a Workbook. Creating a dedicated class to handle Application events for specific purpose may help to keep the architecture clean.
However, from the stand point of the feature itself, there is no problem.
Related
In the references window, you can browse to and set a reference to a custom AddIn. For purposes of discussion let's say it is named MyAddIn.xlam. I changed the project name to MyAddIn and it resides in the standard AddIns path. So I have successfully done that and then have defined an associated global variable as below in a different Excel workbook:
Private m_MyAddIn As MyAddIn.thisworkbook
How and when do I instantiate the variable I have defined? It would be simple if I could cast the associated Application.AddIns collection item to my specific AddIn but that isn't an option.
Within the MyAddIn code, I have tried defining a public property ParentWorkbook that just returns ThisWorkbook. I have also tried doing the same in a public class defined in MyAddIn. But I cannot figure out how to instantiate the variable.
Here is what I am trying to do:
MyAddIn raises a custom event MyEvent whenever a Workbook is opened or a new sheet is created
One or more custom xlsbs MyCustom1.xlsb, MyCustom2.xlsb will handle the event
Because the xlsbs are looking for an event, I need to be able to define a WithEvents MyAddIn variable in the xlsbs to be able to handle them
So for example, a PivotTable xlsb might do some custom actions based on PivotTable events. These could all be setup in the xlsb once it received notifications that a new file was opened. It could check to see if a PivotTable was present and skip all others, etc.
Why am I trying to do it this way?
I'm trying to avoid a bunch of chatter. If each xlsb uses the application object to check for open files, etc. they will all run every time a file is opened in Excel
My thought is that only MyAddIn will check that event and then raise the custom events as appropriate so the xlsbs.
I hope this helps.
Thanks for any ideas and/or suggestions.
I think you should trap App level Workbook.Activate events like explained here: https://www.exceltip.com/events-in-vba/how-to-create-application-level-events-in-excel-vba.html
Main points from that page:
Insert a class module. Name it as you want. I named it MyAppEvents.
Define an event variable of Application type with keyword WithEvents.
Initialize this event in class_initialize() subroutine.
Now define the events you want to use. From the top-left drop-down, select the event object.
You can then set wb = ActiveWorkbook and do what you want with it.
First of all, I already found out how to list default event names of Excel UserForm Controls using Typelib Info referenced as TLBINF32.DLL.
I shared it here.
It is a part of my ongoing project to create codeflow diagrams and possibly VBA code obfuscator early alpha version available on GitHub.
The issue now, is, with trying to list Event Procedures of the UserForm itself:
Unlike listing UserForm Controls using TLI-ClassInfoFromObject(UserForm1.CommandButton1), I found out the hard way that I need to use TLI-TypeLibInfoFromFile("FM20.dll") because if I use ClassInfoFromObject(UserForm1), there is an error.
I also found out that I can use TLI-ClassInfoFromObject(ThisWorkbook.VBProject.VBComponents("UserForm1").Designer).
Using FM20.dll and .Designer methods both get 16 event procedure names.
I can manage/understand up to this far.
Then I manually counted the UserForm's event procedure dropdown list in Excel VBA Editor and found that there are 22 UserForm event procedures.
But after I ran the following code using TLI, the resulting list contains 16 event procedures only, as shown in the first photo.
I am using MSForms class/object from FM20.dll.
The code is as follows: (Needs Reference to TypeLib Information library at C:\Windows\SysWow64\TLBINF32.DLL)
Sub listUFEvents()
Dim t As TLI.TLIApplication
Set t = New TLI.TLIApplication
Dim ti As TLI.TypeLibInfo
Set ti = t.TypeLibInfoFromFile("C:\Windows\SysWOW64\FM20.dll")
Dim cci As TLI.CoClassInfo
Dim mi As TLI.MemberInfo
Dim i As Integer
For Each cci In ti.CoClasses
If cci.Name = "UserForm" Then
For Each mi In cci.DefaultEventInterface.Members
i = i + 1
Debug.Print CStr(i), mi.Name
Next mi
End If
Next cci
End Sub
6 events were not listed including UserForm.Activate and UserForm.QueryClose etc.
My question is, why those 6 event procedures were not listed?
If these event procedures were not picked up from the TypeLib in FM20.dll, where do they come from?
Object Browser also shows only 16 procedures.
Or did I do something wrong in using TLI library?
I admit that I am pretty far from becoming/being an expert.
I am still trying to understand how TypeLib Info works.
How do I get all 22 event procedure names?
I need the event procedure names to differentiate user-defined procedures from the event procedures in a UserForm CodeModule in my project which is about listing the procedure calls in a VBA project.
I can't find anybody asking the same question anywhere either.
Edit:08FEB2021
Added project userform image + zoomed one, to clearly show and better explain the question
In the following zoomed photo,
A->, UserForm controls' default event procedures' names
B->, UserForm default event procedure names
C->, User-defined Sub+Function residing inside UserForm CodeModule
Above image is zoomed for better clarity.
***********************************************************
I want to separate B from C like I did with A.
***********************************************************
So that we can know that default event procedures were NOT called directly.
The image below is presented to get a better idea of why I am needing to list the names of the UserForm event procedures.
Apology
I apologize for being a bit political (if you wanna call a function name politics!).
I truly am sorry to have to involve a bit of politics here.
I am not asking for anything except your awareness. Give me a negative vote if you want, for doing what a man needs to do when his country needs him most.
I just want to do something, however small it may be, as a citizen of Myanmar.
Normally, I am not interested in politics but the current situation calls for me to let the world know that Myanmar is currently under siege by a Military coup which forcibly removed democratically elected government and currently oppressing its citizens' rights.
Please bear with me and I hope you all can understand and empathize with me.
Thanks for your kind understanding.
The TLBINF32.DLL does what it is designed (coded) to do, so there is nothing you can do to make it recognize the five events related to MSForm's multiple "open/close" steps, or the MSForm's own window's Resize events. If you want to use them in your code you can, for example, create string constants for the event names you need, or keep them in a lookup table in a worksheet, or in a text file you will read, or whichever other way that suites your project.
As for listing Excel UserForm Controls, you do not need TLBINF32.DLL at all because it's already built (obviously, since TLBINF32.DLL just taps into this) into the MSForm class. To test this, please create a form, name it, say, "Form1", throw in a few controls and run the following simple subroutine from anywhere within the VBA project:
Sub ExamineControls()
Dim ctl As Control
For Each ctl In Form1.Controls
Debug.Print ctl.Name, ctl.Top, ctl.Visible ' anything else you need?
Next
End Sub
It does not matter whether the Form1 is opened or not.
I hope this is helpful.
I am developing an Excel VBA project using the "Worksheet abstraction\Worksheet Proxy" technique, described in the There is no worksheet article and followed-up in my question here. My VBA code is structured in the MVP design pattern and I have written as much OOP code as possible. Rubberduck's "Code Inspections" feature has been of great help along the way, however in more recent versions (I think since v2.4.1.4*** but can't exactly put my finger on the exact version) I started to consistently get a couple of "Rubberduck Opportunities" and "Code Quality Issues" warnings that I can't quite make sense of.
The first one, as mentioned in the title, is the Member 'x' has a 'VB_VarHelpID' attribute with value '-1', but no corresponding annotation Rubberduck Opportunity. I get this one whenever I am declaring an event-exposing Worksheet (or other event-exposing object, i.e. a CommandButton) inside a "WorksheetProxy" class. Both lines in the below code would trigger this error:
' This code sits in my ProcessMasterProxy class
Private WithEvents sheet As Worksheet
Private WithEvents buttonHideOwnerToAvailability As CommandButton
Then I would get the same error in my "Presenter" class whenever I declare an instance of an event-exposing "SheetProxy" class, or an event-exposing UserForm:
' Here I am declaring an instance of the ProcessMasterProxy class from the above snippet
Private WithEvents assetPrx As ProcessMasterProxy
Private WithEvents view As ChecklistPopup
Rubberduck's Code Inspections offers me two actions for such errors:
1. "Add attribute annotation" which inserts the '#MemberAttribute VB_VarHelpID, -1 line above the declaration AND
2. "Remove attribute" which seems to do nothing, the error remains after clicking it.
I would like to know what implications does the "Add attribute annotation" fix bear on my VBA project and whether I should apply it or rather look to change something in my code to avoid getting the error altogether.
Similarly, I am concerned about a related error I get in the "Code Quality Issues" section: To the variable 'sheet' of declared type 'EXCEL.EXE:Excel.Worksheet' a value is set assigned with the incompatible declared type 'ProcessMgmt.ProcessMaster' which is related to the following code in the "ProcessMasterProxy" class from the first snippet above:
Private WithEvents sheet As Worksheet
Private WithEvents buttonHideOwnerToAvailability As CommandButton
Private Sub Class_Initialize()
***Set sheet = ProcessMaster***
Set buttonHideOwnerToAvailability = ProcessMaster.btnHideAssetOwnerToAvailability
End Sub
with "ProcessMaster" being the name of the actual Excel Worksheet and the above code sitting inside its corresponding "SheetProxy" Class.
The only option offered by Code Inspections for this error is "Ignore once" and again I would like to know whether it is safe to do that. I have had this errors appear in a couple of projects before, yet everything worked fine there. However, in my most recent project I started randomly getting a “Run-time Error 35010” when opening the workbook, where I have the following code in my Workbook_Open event:
Private pres As Presenter
If pres Is Nothing Then
Set pres = New Presenter
End If
Could this problem be related to any of the above two Code Inspections suggestions/errors?
The role of these inspections is to surface hidden attributes that the VBE might be adding. Often these attributes affect how a class can be used (VB_Exposed, VB_PredeclaredId), or how a member behaves (VB_UserMemId, etc.). But they are also completely invisible in the editor, and without a corresponding annotation/comment, it's often impossible to tell their presence.
In this particular case Rubberduck is informing you1 that there's a hidden VB_VarHelpId attribute on the WithEvents variable.
By adding the corresponding annotation comment, we're making hidden code visible and modifiable in the editor: change the annotation's argument value, and Rubberduck inspections will now say attributes and annotations aren't synchronized, which means the hidden code says one thing but the visible comment is saying another.
Removing the attribute should have had the effect of exporting the module to a temporary file, modifying that file to remove the hidden attribute, and reimporting the modified module into the project. Note that because document modules (e.g. ThisWorkbook, or sheet modules) cannot be imported into the project that way, this doesn't work in document modules, so Rubberduck shouldn't warn about desynchronized annotations/attributes in these modules. If the quickfix didn't do anything, please report a bug, because this should definitely work! (edit: confirmed working as intended with build 2.4.1.5229)
Bottom line, "Rubberduck Opportunities" inspections are just that: opportunities to leverage Rubberduck-specific features (like annotation comments managing hidden attributes): they aren't indicative of anything wrong with the code.
The "incompatible type" inspection result is a known issue: at the moment Rubberduck is not seeing the Worksheet interface of worksheet modules (nor the Workbook interface of ThisWorkbook), and this is causing a number of false positives around document modules. Until Rubberduck can tell that ProcessMaster is not just a ProcessMaster object but also a Worksheet (we'll have a fix for that in 2.5.x), it's probably safe to ignore that inspection when it's complaining about document modules and MSForms interfaces (which have the same underlying issue).
The idea behind this inspection, is that often VBA will only realize at run-time that object types aren't compatible, but (assuming it sees all interfaces of all types) Rubberduck can tell you about a problem at design-time, well ahead of execution.
As for the intermittent error, I suspect it's because you are accessing objects before they are actually available to use. The Initialize handler of your class runs at the New Presenter statement, before the call returns with the reference to assign pres.
I'd try to see if moving the code from the Initialize handler and into some parameterized initializer procedure would fix it.
If pres Is Nothing Then
Set pres = New Presenter
pres.Initialize ProcessMaster
End If
Where this Initialize procedure might look like this (untested):
Public Sub Initialize(ByVal masterSheet As Worksheet)
Set sheet = masterSheet
Set buttonHideOwnerToAvailability = masterSheet.Buttons("btnHideAssetOwnerToAvailability")
End Sub
The idea being, to inject the worksheet dependency rather than couple it to the presenter class (that's a very good thing!), but mostly to let the class instance initialize itself fully before we start accessing the host document (which has just opened and may have some asynchronous initializations that have yet to complete... just thinking out loud here, this may or may not be what's actually going on).
1 The severity level of each individual inspection can be configured in the settings.
I have this code here and what the code around it does is not important, it runs properly. However at the point highlighted I need to trigger code in the "SCP Status Paynter" sheet I point to, to get triggered to run BEFORE the code below that point. I dont want to just put in another button or something I just want it to hit that point in the code and run the code in that other sheet. Havent been able to specifically find what I need on google and im new to this so im not sure what to do. Thanks!
The VBE's Project Explorer is making it rather hard to tell/guess what specific procedure you intend to invoke (Rubberduck's Code Explorer drilling down to procedure-level nodes would have helped here! Note: I'm one of the admins on this open-source project), but anyway it looks like you need to invoke a procedure located in the Sheet1 document module.
Say your procedure looks like this:
Public Sub DoSomething()
' do stuff
End Sub
Then from anywhere in your project, you can do this:
Sheet1.DoSomething
Which isn't any different than when you do this:
MsgBox "hello, world"
That's invoking a public/global-scope function located in a standard library function, whose fully-qualified name would be:
VBA.Interaction.MsgBox "hello, world"
Now, if your procedure looks like this:
Private Sub Worksheet_Change()
' do stuff
End Sub
Then you have a problem: it's Private, and it's an event handler. Event handlers can be made Public and invoked as above, however a better practice would be to pull the body into a separate procedure, like this:
Private Sub Worksheet_Change()
DoSomething
End Sub
Public Sub DoSomething()
' do stuff
End Sub
That way you leave event handlers alone. Worksheet event handers are meant to be invoked by Excel, not user code; the same applies to e.g. CommandButton1_Click handlers: they're meant to be Private and invoked by the MSForms library, not by user code. Making it a habit of implementing logic outside of event handlers (and make them invoke the logic instead), is a very good habit to take early on.
I have been trying to call a Private Sub CommandButton1_Click(), which is behind the user form LoadQuoteDetails2, from a different module using the line of code below:
Sub Automation()
Application.Run "LoadQuoteDetails2.CommandButton1_Click"
End Sub
However, it throws me the following error:
Run-time error '1004':
Cannot run the macro LoadQuoteDetails2.CommandButton1_Click. The macro may not be available in this workbook or all the macros may be disabled.
However, I am sure that the macro is present within the workbook. Does anyone know the reason why might this be happening?
If not this, is there a different way to call a private sub behind a user form from a different module?
Note that I do not want to change the user form or the code behind it in any way; for e.g. making it as public or adding a public module behind the user form which calls the private module etc.