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.
Related
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 am currently working on a VBA project in Excel where I need to unlock a VBProject and also lock another VBProject. So far, I have been doing this with SendKeys, but I keep reading that it is not a good method, and that API is better? (For example in this thread: Unprotect VBProject from VB code)
However, I could not find any detailed information as to why during my research.
Could someone please tell me why exactly SendKeys is bad? What are the things that could go wrong? (Please note that my SendKeys sequence is only 1.5 seconds long at most.)
Also, why is API the better approach?
Thanks! :)
WinAPI uses things like window handles (you may have seen hWnd in code before?) to target a specific window. Once you have this you can send and receive messages to that window regardless of it's window state (active/inactive) etc.
You are working directly with the object, which is the way programming should be.
The SendKeys() method just emulates a user hitting keys on a keyboard, irrespective of what window is open and where - so it naturally sends the output to whatever object is active and able to receive it.
Another way to think about it
If you're coding to place a value in a cell on a certain sheet in VBA you can do the following:
Range("A1").Value = "Foo"
This is all well and good, but it assumes that the sheet we want is the active sheet at that moment in time. If it isn't, the wrong cell on the wrong sheet will be populated instead. This is effectively what you are doing with SendKeys()
This on the other hand:
Workbooks("Target Workbook.xlsx").Sheets("Target Sheet").Range("A1").Value = "Foo"
Specifies the exact cell, in the exact sheet, in the exact workbook that we want to target - so if that sheet isn't active at that point in time then no worries! It will still go to the right place (this is kind of what you're doing with API)
A WORD OF CAUTION
Playing with WinAPI in VBA can be risky if you don't know what you're doing - the code for these methods is pre-compiled in an external library which means your VBE error handler isn't going to be of any use. If you make a mistake with API you run the risk of corrupting your workbook (or worse depending on what you're actually doing).
You also need to look at conditional compilation in VBA, because you have to declare functions and parameters differently depending on whether you're using a 32-bit or 64-bit version.
As of yesterday, I had a working macro that generated histograms using analysis toolpak (VBA). As you can see below, the analysis toolpak VBA add in is enabled, and I have set a reference in VBA.
The file is saved as .xlsm (macro enabled) and I can produce histograms without a macro:
But if I record a macro to make a histogram, I get this same error. This is happening for all functions within the analysis toolpak. What happened here?
... I'm going to have to call this one solved. Very VERY strange error that must be related to this
error message I received when I disabled both the analysis toolpak and the analysis toolpak for VBA add-ins. My code is back in working order after disabling/re-enabling these add-ins. Maybe someone knows exactly why this is happening, but I have to guess that add-ins are handled as hidden workbooks with VBA functions and something strange happened to that workbook. No clue.
my issue was that when I run the macro (to create a histogram), the first time, it runs normally but when rerun it, it gets the error, mentioned above.
I solved it by unchecking atpvbaen.xls from the references.
I am making a primitive database in Excel and need a routine to run in the background constantly. I will be able to fill in the actual actions it needs to do, but I don't know how to make something run independent of a key press or some sort of Macro. If someone can give me an example of code that runs independently which I can simply fill with contents, that would be much appreciated.
Try this http://www.ozgrid.com/Excel/run-macro-on-time.htm
I haven't worked with VBA for quite some time now, but you would have to create a thread in VBA, maybe by COM-Threading, but I am not too sure if Excel is threadsafe or if you even can use Threads of some kind in Excel. Another alternative would be a Timer. If it is not implemented in VBA and I don't remember it to be, you would have to create the Timer yourself and react to the Windows Message yourself, if you can do that in VBA.
All in all I think this uses case might be to big for an Excel VBA Macro. If I were you I would consider doing this in a different way.
Possibly, my questions do not presume a simple answer as I'm asking to share a specific experience.
What kind of issues you experienced trying to execute Excel macros through COM Automation?
Are there any specific requirements for creation of macros to be run through Automation?
Can you share your experience with data (scalar and vector parameters) pass-in / pass-back for macros run through Automation?
I have tried some ideas already and it worked; but I'd like to find out if someone had gone through that way and what issues to expect - before I invest time and resources in building the framework.
Finally, I will share here results of my investigation and decision made at the end.
Thank you,
Albert Gareev
OK, this is what I have so far.
1) Issues.
Every single exit point on COM Client should have proper disconnection routine so that Excel.Application is properly shut down and released. If COM Client was executed in debugging mode, and execution was manually stopped, then shut down Excel.Application manually too (from Task Manager).
2) I currently use worksheet to pass in parameters and retrieve the results.
Additionally, for a data parsing task executed within macro I pass-in text files names. The contents is read and normalized from the Excel macro side.
Thanks.