enter image description hereWhen I execut the Code when the function of DLL calls it give error 429 "Active X component did not Create Object"...
Here i depicted the VBA code which i use.
I also include the libraries..
Sample.tlb
Microsoft Active X 6.0 Object Library
'Microsoft Office 14.0 Access Database Engine Object'
I run this code in MS Office 2010 64 bit and 64 bit Operating System.
This might help. It looks like your Activex component must yet be registered.
Related
I wrote some VBA in Excel 2013 which references Outlook and is now used on a virtual machine. My laptop was upgraded to Office 2016 last week, I made some changes in this tool and then it failed to run on the VM.
Turns out the VBA Outlook reference in the file changed to v16.0 (Office 2016) and so when the VM tried to run the code (on 2013), it couldn't find this reference.
There was also the generic Office reference which stayed as v15.0 though.
I haven't been able to find any documentation on this - is this standard behaviour and if so, any ideas on how I can make further changes to this file without the reference messing up every time?
This is standard behaviour.
You need to move from Early to Late binding. Remove the Outlook reference in VBE and declare the outlook application as Object in code.
Dim olApp As Object
Set olApp = CreateObject("Outlook.Application")
Bare in mind by doing so you will lose intellisense and you may have to change some constants to their numeric values, e.g. olMailItem to 0.
Make sure you have Option Explicit at the very top of your module(s), as this will highlight compilation errors.
I have created a C# .NET DLL with Release/AnyCPU as per http://www-01.ibm.com/support/docview.wss?uid=swg21230705 and successfully registered it for COM Interop.
When I open my 32bit Excel on a 32bit Windows 10, and use the code
Private Sub CommandButton1_Click()
Dim obj As Variant
Set obj = CreateObject("MyTest")
MsgBox obj.AppendStr("This is")
End Sub
it returns the expected values. When I open 32bit Excel on a 64 bit Windows 8.1, and use the same code, it also returns the expected values. The same goes for a similarly crafted VB6 executable deployed on both systems.
But when I try the same from Notes 32 bit using the code
Sub Click(Source As Button)
Dim obj As Variant
set obj = CreateObject("MyTest")
MsgBox obj.AppendStr("This is")
End Sub
it returns the expected values on a 32 bit Windows 10
it throws the error "Could not create automation object" on a 64 bit Windows 8.1
Furthermore, and this is the most interesting part for me, it throws "Could not create automation object" when run as a LotusScript http agent on the Domino 64 bit server on a 64 bit Windows Server system.
Do you have any ideas how I could get the DLL function call to work with both 32 as well as 64 bit Lotus Domino Server?
Or are there any other ways to call a single function in my C# DLL from Notes, which takes a single string as parameter and returns a byte array? (e.g. through a Java agent, through a Domino shell object, or both?)
I just found the solution, and it wasn't a Domino problem at all. The linked tutorial is for pre-64bit systems and says:
To make the objects in this DLL accessible via the COM interface, enter the following command:
regasm MyTest.dll
Since the introduction of AMD64, you have to read this step as follows:
To make the objects in this DLL accessible via the COM interface for both 32 bit and 64 bit applications, enter BOTH the following commands:
%Windir%\Microsoft.NET\Framework\<version>\regasm MyTest.dll
%Windir%\Microsoft.NET\Framework64\<version>\regasm MyTest.dll
I only did the first, which made it work for 32bit, but not for 64bit.
To answer the question in a technical aspect, you can call yout 32 bits DLL by copying it to Windows\SysWow64.see Can a 64 bit EXE link against 32-bit DLLs? for more details.
To answer your need we just need to transform a string to byte array.
You can do this in java and use ls2j to call it.
I also think to use the lib of native consumer to dothis.
Look also at https://www.experts-exchange.com/questions/23120423/Using-NotesStream-to-convert-a-string-to-a-byte-array.html it give you a lotuscript solution.
I have a VB.NET 2010 program that works perfectly with MS Office XP. Because of security concerns attributed to Office XP, I recently upgraded to MS Office 2007. I made no changes to the VB program.
A single Build Error, Type Excel.Global is not defined. is preventing the program from running. The ErrorList points to the UpgradeSupport module as the location of the error.
The entire UpgradeSupport module is as follows:
Module UpgradeSupport
Friend DAODBEngine_definst As New DAO.DBEngine
Friend ExcelGlobal_definst As New Excel.[Global]
End Module
The instance of Excel.[Global] above is the only visible instance of it in the entire program, and there are no instances of Excel.Global at all, anywhere. The variable name, Excel.Global (or Excel.[Global]) suggests a structure. Moreover, I believe Global (or [Global]) is a property, not a type, and I believe Excel.Global and Excel.[Global] are not equivalent expressions. I can successfully define structure Excel.[Global] as follows:
Public Structure Excel
Shared Property [Global] As Object
End Structure
Note: The above will not define successfully without the square brackets around Global, which supports my assertion that the two expressions are not equivalent. I question whether any instance of Type Excel.Global exists in the program. Nevertheless, the Build Error continues to prevent the program from running. How can I eliminate the Build Error?
'In VBA one disadvantage of calling a class procedure with CallByName ist that when an custom error was raised in the called object procedure, the caller always gets error 440 regardless of the original error number being raised.
Microsoft gives a workaround in this article http://support.microsoft.com/kb/194418/en-us.
It suggests instead of CallByName the use of InvokeHook. Therefore the library "TypeLib Information" (TLBINF32.DLL) must be added as a reference.
My question is: is this library available by default on every Windows PC, where only MS Office is installed (no Visual Studio etc.)?
Thanks in advance for your answers
Where I'm at the developers have been updated to Excel 2007, but most of the users haven't. I'm building a spreadsheet template (*.xlt) for a user that's gonna need some vba code included, and I'm wondering what issues I'm likely to run into building this in 2007 instead of 2003? I don't have access to a machine with Excel 2003 for testing, and I'm worried this particular project is headed for disaster.
The VBA language hasn't changed, but there are additional objects in Office 2007 that are not in Office 2003. Naturally, this will cause a runtime error when you try to access these items in a 2003 environment. What's stopping you from setting about a virtual machine with Excel 2003 to develop under?
Rather than depending on a probably incomplete list of objects and methods which have been added to Excel 2007's object library, the best (mmost relliable) practice is to always develop in the oldest version of Excel likely to be used to run the code.
One difference I discovered is that a subroutine must have a different signature to be called from a menu (in Excel 2003) than when called from the ribbon (in Excel 2007). Whatsmore, Excel 2003 doesn't recognise IRibbonControl and throws compile errors.
To work toward cross-version compatability, I use a Conditional Compilation Argument and then check that in pre-processor macros.
e.g.
#If USINGRIBBON Then
Public Sub CallFromRibbon(control As IRibbonControl)
#Else
Public Sub CallFromRibbon()
#End If
' Code here
End Sub
This does mean that you have to save one version of your add-in with the USINGRIBBON flag set to false (for Excel2003) and another with the USINGRIBBON flag set to true (for Excel2007), but this is far easier than maintaining two completely separate codebases.
billb2112 is right. There are numerous changes to Excel 2007 over excel 2003 that are not backward compatible. While the language might not have changed, the objects have been updated. Some have had additional properties added, some work differently and some functions in Excel have changed.
You need to be very careful that what you code works in Excel 2003.
I would suggest as billb2112 said that you get a virtual machine to not only test in but also to code in. I do all my Excel development for clients who only have 2003 in a 2003 machine. Note that if users have Excel 2002 or 2000 there are even more differences as you go back and you will simply get runtime errors on any code that these older versions don't support.
update
unfortunately jeffs answer is not quite correct. while yes the vba language hasn't been updated it is not the same in 2007 as in 2003. as in 2003 its not the same as in 2002 etc.
what has happened is extra and additional functions and arguments for functions have been added. for example there are more options in the FIND function in Excel in 2003 than in 2002. thus if you record a macro (the best way to find these problems) in 2003 and then run it in 2002 you will have run time errors relating to the new arguments that simply do not work in the 2002 VBA editor. following the same process for functions that have changed in excel 2007 and then going back to 2003 to test will help you locate these problems. some examples include conditional formatting, colours (themes) and numerous new spreadsheet functions.
jon peltier has the best advice from that regard - develop in the oldest possible version that the client /user will use.
Virtual PC 2007 is free to download and install. you will just need a licensed copy of XP/Vista and office to install to run in it.
i used to develop a lot of macros under 2003, what a POTA,, things like Find, Dir and some others are not available or something change. therefore some erros can be expected, i used to count from 65000 row to the first non empty row to count the rows to work on.... now more rows means more work to do