Just have no clue why the code below kept complaining about "user defined type not defined":
Dim ownControl As Control
I saw all other resources online used this code without any problem. Really confuse on it, hope someone can explain to me.
By the way, I'm using MS Excel 2007. Thanks a lot
Most likely you will need to first add a UserForm to your workbook (assuming you're going to be using one) or instead add a reference to "Microsoft Forms 2.0 Object Library".
The Control type is defined in that library.
Related
My problem seems very basic and I was surprised to not find an answer after searching. So I would like to keep my library references between startups of Excel but they seem to reset every time.
I am using dictionaries in my VBA code so I need Microsoft Scripting Runtime enabled. How do I keep this reference up? Or is there a way to force it through my VBA code? This would actually be the best solution as this tool is going to be used by a few other people in my organization.
Someone has a solution to this? Any help is greatly appreciated.
With this question you're essentially getting into the topic of early binding vs. late binding.
I'm assuming what you're doing now is early binding, which means you are adding the reference manually from the tool bar.
To persist the reference I'd suggest going with the late binding route.
Add the following lines to your code:
Dim dict As Object
Set dict = CreateObject("Scripting.Dictionary")
From there you can access the dict object by doing dict.method/function.
I'm providing you a few examples below that should help you get the idea of how to utilize this:
dict.add key, value
dict.remove key
dict.count
Given you're already working with the dictionary you probablly have a general understanding. If you need to understand more of the built in methods/functions refer to the following documentation:
https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/windows-scripting/x4k5wbx4(v%3dvs.84)
MS Access 2016 running on Windows 10.
I am debugging VBA changes to a MS Access application and am seeing some unexpected interactions between the VBA editor and running code. The steps are basically:
Open the application, which opens startup form.
The startup form_load instantiates an object used by other forms the user may subsequently open.
Open the VBA editor
Using the VBA editor, select a line in any code module and the instantiated objects are set to nothing.
An error is thrown when the other forms using the object are opened.
So basically, the VBA editor action has set the objects to nothing. I have added instrumenting code to confirm this.
Has anyone seen the behavior? Does anyone have thoughts about what may be happening and causing this?
Thanks in advance...
Additional information:
The code instantiating the object in the Form_Load method is:
Set musrInfo = New usrInfo
Where usrInfo is a class module containing user information.
Also, there is no problem with earlier versions of this - I have never experienced the described problem with any other MSA VBA application. The compiled version of this particular MSA file is a bit bigger than 20MB, with little in the way of data tables - only a few parameters, etc. - and more than 13MB in forms, reports, etc.
I hope this helps... Lindsay
And there's more...
- I tried this .accdb file on another PC with Win7/MSA2010 and this
behavior did not occur.
- I then tried it in a different folder on the original PC and it
did not occur.
Maybe these findings will allow a path forward, but I still wonder why this would ever happen - why would the folder choice make any difference?
This is usual behavior.
When making changes using the VBA editor, it may recompile the VB project behind your database. This can be the whole project, or parts of it, depending on the exact change.
Recompiles will clear any variables.
You can change this behaviour, by going to Tools -> Options, under the General tab. See the following screenshot.
However, even with Compile On Demand off, you will have to trigger a recompile for most changes, clearing any set variables.
For classes that need a single instance to be publicly available as long as the database is open, I recommend setting the VB_PredeclaredID to true. That will instantiate the object as soon as the database opens, or the code recompiles. See here how.
I got a problem regarding late binding, and hope there is someone who can help me.
I have searched Google dry regarding my issue, and most solution do not fit at all.
I am binding a Excel macro written in VBA to my own program to communicate, it works fine with GetObject(). However GetObject() gets a random instance, and I don't want that since there can be multiple instances open at the same time.
When I open the Excel through a C# program, I pass the window handle and process ID of the newly opened instance as arguments to the excel.
How can I do a late binding in Excel VBA by only using either process ID and / or window handle?
Thanks in advance.
I have been searching this for a while without any positives . We can create new modules, form ,report, but macros .Can we at all do this? This post asks the same question but answers another one.
"Create a macro for Microsoft Access via Interop "
here VBA module is being added not macro.
Theoretically it seems feasible as macro is an access object so why we cant do it ?
I dont think you can create macros via vba.
There is an object AllMacros (Application.currentproject.allmacros) and its members are representations of the individual macros in your project - but they are of the type Object, thus there doesn't seem to be any vba representation of the macro object.
You also can't import macros, autogenerate them or convert from vba to macros... So it seems pretty obvious ms isnt encouraging using them and hasn't done anything for us to create them
I have a Microstation macro that reads the reference files in the current drawing and then prints them to a text file. We are working on getting this running for the new Microstation v8i (upgrade from v8). The macro normally runs through each reference file (from index = 1 to MbeRefFiles.maxRefFiles) and finds the active reference for output.
Now instead, it keeps throwing an Object variable not Set error when referencing the MbeRefFiles(index) object. I'm just doing a Set refFile = MbeRefFiles(index) and it says MbeRefFiles isn't set, which doesn't make sense because it doesn't need to be set. The macro is completely unchanged and has been working for years, and now suddenly it can't read the reference file object. Anyone have any insights?
As far as I know, you have to use VBA than you can get more comfortable support.Microstation's VBA is based on Microsoft's engine while MBE is cooked by Bentley.
MicroStation BASIC became obsolete in 2001 when Bentley Systems released MicroStation v8.
Prefer to use MicroStation VBA. It fully supports MicroStation V8 where MicroStation BASIC falls short. MbeRefFiles.maxRefFiles is an example of the shortcomings of MicroStation BASIC. MicroStation VBA provides a collection (ModelReference.Attachments) that you can iterate using VBA idioms.