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.
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 have a C++ *.h file with three classes in it. The header file is for accessing a DLL. I have almost no C++ knowledge. However, I seem to recall from somewhere that you can't convert a *.h file to a Delphi unit that has classes in it. Is this true?
If it isn't true, and classes in header files aren't a problem, what is the general approach to converting the classes to Delphi?
C++ classes, just like Delphi classes, are not designed for binary interop.
A Delphi class can only be exported for consumption by other Delphi code, and then only in a package, and only when runtime packages are in use, and only when all modules use the same version of Delphi. In a similar vein, C++ classes can only be imported from a DLL by code compiled with the same tool chain that compiled the DLL.
So, it is not possible for your Delphi code to consume this DLL. As I see it you have the following options:
Persuade the supplier of the DLL to provide an interop friendly interface to the library. For instance, a plain functional C style interface, or a COM interface.
Write an adapter in C++, using the same compiler that was used to build the DLL. That would involve you importing the classes into your wrapper and exposing them to your Delphi code in an interop friendly manner. Again, plain C style interface or COM are the obvious choices.
In the sense of allowing you to use the DLL from Delphi code? Yeah, good luck with that. You know how you can't use Delphi classes in a DLL unless the client code is written in the same version of Delphi and even then it's usually a bad idea due to shared memory management gotchas? C++ poses exactly the same problem, only exponentially worse because there's no standardized ABI and there's all sorts of C++-language screwed-uppedness making problems for you.
The only real way to make it work reliably is with an interface that uses a standard ABI. If you have the source, try making a C interface that wraps the C++ interface. If not, ask the person who wrote the DLL to provide a C interface, and ask whoever made the decision to use this DLL why you're using a 3rd party library with no source available. :P
As commented in a previous answer the solution is using SWIG in order to generate the pascal binding. I started the development of the SWIG's pascal module but I had not time to complete it. Basically it works but it lacks all the test cases to be integrated into SWIG.
I used it in my personal projects and I was able to import complex library as GDAL.
I am trying to use the COM system for VCProjectEngine. It is pretty simple to use in C# but I am hitting a wall in native C++.
I am using the COM system and so far I was able to get a pointer to the VCProjectEngine interface using the CoCreateInstance function.
But now what should I do with this interface? I would like to access the VCProject interface to be able to add files to the project. I tried to go with LoadProject or CreateProject but it takes a IDispatch parameter not a VCProject one.
Can someone help me with that?
Calling COM interfaces from C++ can be done in a number of different ways:
"low-level" COM calls using CoCreateInstance and the IUnkown interface
ATL (Active-X Template Library) which provides a number of smart pointers and utility functions to make the job a lot easier. Use in conjuction with #import to generate wrapper classes for you.
For Windows Store Apps you should use C++/Cx or WRL (Windows Runtime C++ Template Library)
There are many good tutorials and code samples on MSDN.
I have a need to create a C++ non-dotnet DLL that will be called and used by a VB.net application. I am trying to determine the type of DLL to create. The DLL will contain some classes, variables, and functions that I will be writing. I understand that there are three types of a DLL that can be created: 1) Regular DLL - Statically Linked to MFC, 2) Regular DLL - Dynamically Linked to MFC, and 3) DLL that uses the Standard Windows Libraries, non-MFC.
My question is, which would be the best to use, one that is linked to the MFC, or one that uses the standard windows libraries? Can someone make a suggestion and explain the differences between MFC and the standard libraries?
Thanks!
Gary
Microsoft Foundation Classes (MFC) are a relatively thin C++ wrapper around the Win32 API, with an emphasis on UI coding. You won't need to statically or dynamically link MFC to your DLL unless you are making use of MFC facilities such as its container classes or trying to display UI written with MFC in your C++ DLL. These are unlikely scenarios.
People have been calling unmanaged code from VB.NET since .NET began. There's a whole wiki available on the subject here at http://www.pinvoke.net/ and there's a useful walkthrough on CodeProject, http://www.codeproject.com/Articles/6243/Step-by-Step-Calling-C-DLLs-from-VC-and-VB-Part-2 as well. I recommend starting there.
It's a little more complex, but you can also write managed code in C++ by using C++/CLI that can be referenced just like any other managed code assembly instead of using platform invoke. You can use it to create VB-callable managed interfaces that call unmanaged, plain old C++ code. There's an introduction to C++/CLI on MSDN at http://msdn.microsoft.com/en-us/library/ms379617(v=vs.80).aspx and a quick example of using it as a shim for unmanaged C++ in this MSDN Blog entry: http://blogs.msdn.com/b/junfeng/archive/2006/05/20/599434.aspx
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