I am still a bit new to Windows programming and sometimes find the documentation and tutorials I find confusing and sometimes contradictory but I hope I can make some sense and be corrected on any points I am mistaken about.
I am using an API where the documentation included is quite poor. It is made up of a number of DLLs that they envisioned would be added as a reference to VB projects (most of the users are biologists/chemists and are not very familiar with other languages, so they recommend VB). I thought they were .NET dlls at first but they cannot be registered with regasm and a tlb cannot be generated using this but can be registered with regsvr32, so I guess that means they are COM dlls...please correct me if I am wrong.
My understanding is that as this exposes the COM objects that I should be able to use this with .NET languages and unmanged c++. I have used it in C# but I would also like to use this in unmanged c++. I have seen tutorials like this:
http://cppkid.wordpress.com/2009/01/...nmanaged-code/
That import the type library but I do not have this, it was not supplied with the API. However using OLE viewer I was able to see that they were available (embedded in the dll?). I was wondering if anyone knows how I can go from this to actually using the dll in c++.
Cheers and thanks for any help.
I guess the easiest way to achive this would be to use the #import directive:
#import <mygreatlib.dll>
There are other ways though, like using #import with the ProgID of the entry point class of your dll, or using the MFC type library wizard
Related
Ethovision is an old computer vision software writen in c++ used mainly for tracking mice. It has the possibility to Real Time Export this data and i have been given the task to establish a program that use this data. i am quite confused on how as i am a beginer programmer and have only done web design so far.
I have been provided with some IDL files but i have no clue what im supposed to do with them and im just really confused in general. Does any one have any general idea on what i should do/read to extract this data.
Sorry if this sounds dumb, im new at this.
Q. If its a typelib does it mean the functions are defined within that file? or are they somewhere else? If theyre defined in c++ how would i import them in another language?
No. The interface is only described in that file. But in the case of COM "type libraries", there will be GUID identifiers for
the type library
classes (co-classes)
interfaces (IUnknown/IDispatch derived)
search the registry (regedit.exe, regedt32.exe) for the typelibrary GUID to find what registered COM component implements it.
If it's a wellknown component, dropping the GUID in Google could reveal some useful documentation
You can import these in many languages that have COM interop, like VB6, C#, VB.Net, and yes even C++ provided that you either use MSVC's builtin extensions or external libraries to make it workable.
I'm going to give some pointers here assuming that you want the MSVC (Visual Studio's C++ compiler) route on windows:
Use oleview.exe to view typelibraries. You can also view dlls that have their typelibraries as embedded resources. You can then save the TLB file separately, or view the IDL
Use MIDL.EXE (The MIDL Compiler), specifically for COM https://learn.microsoft.com/en-us/windows/win32/midl/midl-and-com
I recommand #import directive which basically does the same as generating the header/implementation files and including them in one line
TL;DR Summary
If you can, don't do this from C++. The reason is that COM interfaces speak "high level" types that just require tedious, error prone handling in C or C++ (using wrappers like CComBSTR or bstr_t).
In a language like C# you get all the marshalling and threading ("apartments") guarantees for free.
I want to send an email through outlook.
I want to use the Microsoft.Office.Interop.Outlook library. But the problem is that dll is contains C# methods.
Is there anything that is equivalent to that library? or should I use a different library that is more compatible with C++.
Any suggestions on an appropriate library? any resources pointing to a relevant code will also be appreciated!
Outlook Object Model is not C# specific. The interop dll created when you add a reference to Outlook in your C# project is nothing but a glorified binary header. It does not contain any actual code.
Using OOM in C++ is not any different from using any other IDispatch-friendly COM library - use #import to import the type library, declare and use objects, etc.
I have to use a DLL in my project that is a .NET assembly. I have to use C++ for this project. I'm a relative beginner to programming, so my knowledge doesn't extend too far. I was told COM Interop is one way to get the DLL to work in my project (the other being C++/CLI). The problem is I have ZERO idea how to begin, as I've never done anything like this before, and the Microsoft documentation on the matter isn't really helping.
If anyone can even point me in the right direction, that would be much obliged.
Here are some good resources to get you started:
Introduction to COM
COM from Scratch (Covers using COM from C++)
MSDN's section on COM
That being said, you'll also need to make sure that your .NET project is setup to expose the classes via COM. Make sure to turn on Register For COM Interop in your project settings, and flag appropriate types with [ComVisible(true)] (Unless you make the entire assembly ComVisible, in which case you would flag types you don't want to expose with [ComVisible(false)])
What's the best way to do this....?
I have some Native C++ code that uses a lot of Win32 calls together with byte buffers (allocated using HeapAlloc). I'd like to extend the code and make a C# GUI...and maybe later use a basic Win32 GUI (for use where there is no .Net and limited MFC support).
(A) I could just re-write the code in C# and use multiple PINVOKEs....but even with the PINVOKES in a separate class, the code looks messy with all the marshaling. I'm also re-writing a lot of code.
(B) I could create a native C++ DLL and use PINVOKE to marshal in the native data structures. I'm assuming I can include the native C++ DLL/LIB in a project using C#?
(C) Create a mixed mode DLL (Native C++ class plus managed ref class). I'm assuming that this would make it easier to use the managed ref class in C#......but is this the case? Will the managed class handle all the marshaling? Can I use this mixed mode DLL on a platform with no .Net (i.e. still access the native C++ unmanaged component) or do I limit myself to .Net only platforms.
One thing that bothers me about each of these options is all the marshalling. Is it better to create a managed data structure (array, string etc.) and pass that to the native C++ class, or, the other way around?
Any ideas on what would be considered best practice...?
UPDATE:
I know I can re-write the native C++ code from scratch, but it means duplicating the code and prevents me from easily reusing any code updates with any Win32 application. What concerns me most is the best way to marshal the various data between the managed and unmanaged world. To me, a mixed mode DLL looks like the most flxible option, but I'd like to get a different perspective on the potential pitfalls.
Why not just use .NET directly? It seems to me like your problem arises from the fact that you are dependent on the original native library, but you don't mention that it can't simply be re-done in .NET.
As for .NET-native interop, PInvoke is messy, but it does work. I'd go with that if you can't change the original DLL into .NET.
Option C gives you the least work if the marshaling turns out to be simple and easy for the framework to handle (is everything blittable?). It also gives you a place to hook in your own marshaling. I wrote something about this ages ago marshaling between date types etc but I think today I would write a marshal_as<> overload between your managed and native types. It would be the most elegant solution and also the least code.
Update: found my old article - it was for PInvoke. http://codeguru.earthweb.com/columns/kate/article.php/c4867/
I need to build a C++ library to distribute among our customers. The library must be able to be accessed from a wide range of languages including VB6, C++, VB.net and C#.
I've being using ActiveX controls (ocx files) until now. But I wonder if there is a better kind of library (dll, etc.) that I can build. What do you recommend?
I'm limited to C++ as the library language, but you can mention other languages for reference to other developers.
P.S. Sorry if the question was already asked. I had some trouble finding a suitable title. Feel free to correct my English.
Edit: Seems like the best choice is either DLLs or OCX (i.e., COM), but I'm still having some doubts on which one will I choose. Which one is more suitable to modern languages (.NET for instance)? Which one would be easier to use from an end developer perspective?
Almost every language has a way of loading dynamic libraries and accessing exported C functions from them.
There is nothing preventing you from using C++ inside the dll but for maximum portability, export only C functions.
I have some more about this in this post.
If you're looking at supporting both VB6 and .NET, you're pretty much stuck with exposing interfaces via COM, but at least that'll get you out of having to create more than one wrapper based on the language/runtime system you're trying to interact with.
If there is any chance this will need to be ported to non windows platforms then a DLL / Shared library is your best choice as a COM object really isn't at all portable.
In addition you can call a DLL from almost any platform even if it requires you to write a wrapper of some kind. It's pretty easy to wrap a dll in a com object but if you make a native com object it's a lot harder to add a C style DLL API. Plus you might want to call it from java for example and it's much easier to write a JNI wrapper to call your DLL than get it working with COM in any kind of cross platform way.
Really it depends on what platforms you really need to call it from and how certain you can be that you won't get something out of the ordinary in future.
To be callable from all those languages your only real option is going to be COM, without having to write wrappers where required (which would defeat the point)