How to call .dll coded in vb6 from AutoHotkey Script? - vb6

I need to call .dll file from AutoHotkey but can not while I can access dll from vb6 as follows
//spaceCalculator.dll
Dim obj As New spaceCalculator.calculate
msgbox obj.getData("shapes",2,100,100);
I want to call it from AutoHotkey as follows but throws error -3/-4. .dll in root folder of Script.
DllCall("spaceCalculator.dll\getUsageData","Str","Shapes","Float",2,"Float",100,"Float",100)

Your VBScript uses COM. Your Autothing uses dynamic linking. This is what help says.
VBScript, JScript, and Component Object Model (COM)
VBScript and JScript may be embedded in a script via Windows Scripting for AutoHotkey, which also provides access to COM.
Also, COM may be used directly via DllCall as demonstrated at www.autohotkey.com/wiki/index.php?title=COM_Wrappers.

I have a new ID. While help says you can use DllCall for COM it is very fiddly using COM via DLL function calls (and there's a lot you have to call like CoInitilize and GetClassObject) rather than the runtime doing all the grunt work.
Put your VBScript into your Autoit script as help suggests.
Note in VBScript you have to use late binding so
Dim obj As New spaceCalculator.calculate
Becomes
Set obj = CreateObject("spaceCalculator.calculate")
Although your objects looks wrong. Calculate looks like a method not an object itself.

I found solution that AutoHotKey can dll in which classes are defined like Vb6 and C# as follows
obj:=CreateObject("projectName.ClassName"); // using CLSID
obj.FunctionName(Parameters);
Thanks all

Related

Is it Ok to call managed code from an unmanaged shell extension?

I've read that it's unwise to implement a shell extension using managed code.
But if I go ahead and implement the shell extension using unmanaged code (C++ or Delphi), is it then ok for that unmanaged shell extension to call methods in managed (C#) assemblies? Or must the entire shell extension and everything it calls be unmanaged?

js-ctypes: load a nsISupports from a Windows DLL

Is it possible to use js-ctypes to call a Windows DLL and have it return a nsISupports instance?
The Windows DLL does XPCOMGlue, but by not needing NSModule I hope I can improve the registration process.
I was hoping there was a ctypes.nsISupports type defined to use as return value, so if it's possible, how do I declare the call?
From my reading and experimentation, no, it doesn't look like you can. However, you could do the next best thing.
1. Create a win32 DLL exporting plain "C" symbols.
2. Create a "wrapper" XPCom component using JavaScript.
http://kb.mozillazine.org/Implementing_XPCOM_components_in_JavaScript
3. Plumb each plain "C" function exported by the DLL into the JavaScript object.
Possible improvement: create a generic JavaScript shim that does the plumbing automatically.

Calling a DLL function from tcl via twapi

I have a TCL application that is intented to run on Windows only and uses twapi to access some Windows-specific functions.
Now I need to call some C function that are in a custom DLL.
I know I can load the DLL with twapi::load_library (should be the same as LoadLibraryEx()) but I can't understand how to call a function within the DLL itself!
What did I miss?
I would prefer to avoid other dependencies (like critcl, for example) and to avoid to have to transform the current dll in a tcl extension (e.g. via SWIG) so a twapi only solution would be really helpful!
TWAPI doesn't seem to provide any public binding of GetProcAddress (the Windows API function for getting from the name to the address of a function in a DLL).
Use ffidl for simple APIs (i.e., where there are no callbacks) or critcl (for all kinds of APIs, including those with callbacks, because it can do much more extensive code generation; more effort to use though).
twapi's load_library command is there for manipulating the resources in a dll (string tables, icon etc.). It's not intended for calling functions in the dll since that, as Donal points out, requires marshalling and some code generation.
Looks like you'll have to use ffidl to do the job.

VB 6.0 debugging breakpoint doesn't hit

I have a VB 6.0 Project having Class (cls) files. When I start (Debug) my project, and try to execute following statement in Classic ASP page,
Set objMyObject = Server.CreateObject("ProjName.ClassName")
No breakpoint is hit and following error occurs.
Microsoft VBScript runtime error '800a01ad' ActiveX component can't
create object
While if I use the same statement in another VB Project (test project) then breakpoint hits with no error.
Can anyone help ?
Well you are trying to create an instance of a COM object with the name 'ProjName.ClassName' - which is unlikely to be a real COM object.
Either your COM class needs to be one that has been registered in Windows, or it needs to be a class defined within your VB project.
The example in MSDN is:
Sub CreateADODB()
Dim adoApp As Object
adoApp = CreateObject("ADODB.Connection")
End Sub
Where ADODB.Connection is a COM class that has been previously registered in Windows. The code you have provided above is trying to instantiate a non existant class (unless it is already within the same VB project).
You say that the other project this works, then I will hazard a guess that the test project has a class called ClassName.
Ok -Updated. The error code is not 'DLL Missing' - It is likely to be some reason why the COM object could not be instantiated. The following Microsoft support page suggests some reasons and ways of tracking down the problem. Its likely to be some sort of missing dependency to the DLL.
http://support.microsoft.com/kb/194801

createObject in VB6 does fails when running exe

I have a VB6 program which tries to run a DLL written in C#.
This DLL has a COM interface so I can create an object of a class in it with "CreateObject".
The problem is that it runs and works well when I run it from the VB6 IDE, but when I make an EXE and try to run it, it throws the exception:
"Automation error. The system cannot find the file specified (-2147024894)."
Why is it happening and how can i solve it?
Look at Project, References in the IDE and look which dll or ocx file belongs to the object you are referencing with CreateObject (the Object Manager might also help to find out).
This dll file must be available when the exe is compiled, too. Usually, you need to have it registered with regsvr32.exe.
A technique I use to figure issues of this type is to open the add reference dialog in Visual Basic 6. I scroll the list of available COM Libraries and see if the problem DLL is listed. If it is then CreateObject should work, you should be able to assign it do a variant variant and use late binding to access it's members.
In addition try temporally set a reference to the variable and instead of using CreateObject use the = New and see what error messages, if any, it gives you. Generally I found them to be more informative then the ones thrown by CreateObject.
Finally it would help if you post the reason why you are choosing to use CreateObject instead of setting of a reference. If the DLL is a known object that will be continually used by the program then a reference should be set and early binding generally used.
Finally it may be that the error is resulting from a dependency of the C# COM DLL not the DLL itself. If for example I was to take a Com Library and properly register it but it relies on the COM Library Widget2000 and it NOT registered then it will throw the automation error. Especially if you are testing the EXE in it's installed environment and not the environment in which you complied it.
For example suppose I have a CAD program written in VB6 and I have source tree that begins with MyCAD. THe exe is in MyCAD/MainEXE and the shape library is in MyCAD/ShapeLibrary. I run the IDE everything is fine. Then I make my setup and goto my test machine and install it and it error on the creation of shapelibrary.
The first thing I would do it check if MainEXE will run straight out of the MainEXE directory of my source tree. That test will eliminate whether it is a install issue or a quirk of the IDE vs complied version. Then I would look at the setup and see what not being registered. Also look at either the source for the C# library or the setup for the library and see what dependencies it needs. Since it a complied COM DLL you should be able to use a dependency walker tool to see what COM references it needs. Finally make sure the correct version of the .NET framework is installed.
If you are compiling the C# DLL on your test machine - make sure you have ticked the register for COM Interop setting. If you are not compiling on the same machine you need to run RegAsm with the /codebase option.
try compiling it as an installer and include the dll/com that you use in the compilation of the installer package so that the dll/com that you use will be include in the compilation of your exe.., and install it in the windows not just copy past it.

Resources