Making a program using COM in windows
You are doing really well FireCannon. This is particularly hard stuff. In fact, in my opinion, this is about as hard as it gets.
Before I read your post above, and realizing you were having linking difficulties related to IDEs, I compiled the IDispatch code from the command line. Believe it or not, that isn't hard to do at all, and a lot of us old timers are of the opinion that younger coders just starting out would benifit from this, as it shows how IDEs work more or less. Here is what the command line at the console looks like...
g++ is the mingw C++ compiler. I named my source code file Main.cpp, so that comes right after the g++. Then I listed the four Windows libraries which contain the binary code that the compiler and linker will need to create the executable. Then this line simply lists the name of the output file or executable I want created after a successful compile/link...
-oFireCannon01.exe
And...
-mconsole just states I want a console created. The -m64 says create a 64 bit binary. Finally, the last two are optional, but tell the compiler and linker to optimize for small code instead of speed.
But to get the above to work, when you type 'g++' in a console window the operating system needs to know where g++.exe is located, and it needs to have Main.cpp in the same directory which the command prompt console window is opened. In terms of g++, I believe the installation of mingw puts suitable entries in the Windows Environment Table to find g++. In terms of doing command line compiling work, whenever I intend to do that, here is what I do...
...I make myself a little batch file and put a shortcut to it on my Windows Desktop. Here is the one I made for this program...
The 1st line changes the directory back to C: root. The 2nd line changes the directory again to the project folder where I have the source code files for the project I'm working on. For this work for you I made a C:\Code\CodeBlks\FireCannon\FC01 directory. Finally, the last line opens a command prompt window to that directory, and we're ready for the compilation string posted above. Here is the program above where I've added a call to the Quit() method of the IWebBrowser Interface. Note you need to hit the [ENTER] key once for the Quit() to execute. After the Main.cpp source I have the contents of the command prompt window listed in #if 0 --- #endif conditional compilation statements. Check that particular usage of them out. You might like it...
Before I read your post above, and realizing you were having linking difficulties related to IDEs, I compiled the IDispatch code from the command line. Believe it or not, that isn't hard to do at all, and a lot of us old timers are of the opinion that younger coders just starting out would benifit from this, as it shows how IDEs work more or less. Here is what the command line at the console looks like...
|
|
g++ is the mingw C++ compiler. I named my source code file Main.cpp, so that comes right after the g++. Then I listed the four Windows libraries which contain the binary code that the compiler and linker will need to create the executable. Then this line simply lists the name of the output file or executable I want created after a successful compile/link...
-oFireCannon01.exe
And...
-mconsole just states I want a console created. The -m64 says create a 64 bit binary. Finally, the last two are optional, but tell the compiler and linker to optimize for small code instead of speed.
But to get the above to work, when you type 'g++' in a console window the operating system needs to know where g++.exe is located, and it needs to have Main.cpp in the same directory which the command prompt console window is opened. In terms of g++, I believe the installation of mingw puts suitable entries in the Windows Environment Table to find g++. In terms of doing command line compiling work, whenever I intend to do that, here is what I do...
...I make myself a little batch file and put a shortcut to it on my Windows Desktop. Here is the one I made for this program...
|
|
The 1st line changes the directory back to C: root. The 2nd line changes the directory again to the project folder where I have the source code files for the project I'm working on. For this work for you I made a C:\Code\CodeBlks\FireCannon\FC01 directory. Finally, the last line opens a command prompt window to that directory, and we're ready for the compilation string posted above. Here is the program above where I've added a call to the Quit() method of the IWebBrowser Interface. Note you need to hit the [ENTER] key once for the Quit() to execute. After the Main.cpp source I have the contents of the command prompt window listed in #if 0 --- #endif conditional compilation statements. Check that particular usage of them out. You might like it...
|
|
And the beauty of that is that to get a 32 bit executable all you need to change in the command line compilation string is the '-m64' where you substitute -m32. How's that for easy???
Note in my call to pApp->Invoke(...) above where I'm calling the Quit() method through IDispatch, the call is really easy because there aren't any parameters. With IDispatch work in C++ its the parameters that kill you. They all have to be passed into IDispatch::Invoke() through an array of VARIANTs.
I intend to post further about my Shell.Explorer example because, if I must say so myself, that is really cool. My intentions are to attempt a conversion to 64 bit. So don't attempt yet to use that compiled as a 64 bit executable because even if you somehow get it to compile, it'll instantly crash when it runs. I need to change all the pointer arithmetic and sizes of things to 64 bit. However, it will work fine compiled as x86 code. I worked on that code many years ago long before I was messing with 64 bit.
For anyone else who may be following this thread, that ActiveX Example is particularly complicated because of all the function pointer calls I'm making into Atl.dll. The reason I had to do that was because I wanted the example to work with mingw, and that was the only way I could manage it. I'll provide a bit easier code for anyone using Visual Studio. But later.
Not sure I'll have time for it this weekend though. I really need to get myself ready for a month long cross country expedition I'm making here shortly up to grizzly bear country.
Note in my call to pApp->Invoke(...) above where I'm calling the Quit() method through IDispatch, the call is really easy because there aren't any parameters. With IDispatch work in C++ its the parameters that kill you. They all have to be passed into IDispatch::Invoke() through an array of VARIANTs.
I intend to post further about my Shell.Explorer example because, if I must say so myself, that is really cool. My intentions are to attempt a conversion to 64 bit. So don't attempt yet to use that compiled as a 64 bit executable because even if you somehow get it to compile, it'll instantly crash when it runs. I need to change all the pointer arithmetic and sizes of things to 64 bit. However, it will work fine compiled as x86 code. I worked on that code many years ago long before I was messing with 64 bit.
For anyone else who may be following this thread, that ActiveX Example is particularly complicated because of all the function pointer calls I'm making into Atl.dll. The reason I had to do that was because I wanted the example to work with mingw, and that was the only way I could manage it. I'll provide a bit easier code for anyone using Visual Studio. But later.
Not sure I'll have time for it this weekend though. I really need to get myself ready for a month long cross country expedition I'm making here shortly up to grizzly bear country.
Last edited on
I tried to reproduce the error by adding the invalid path to the library directory list, but it still compiled. |
Not puzzling. Dlls loaded explicitely like that aren't loaded until the program actually runs. That's where the 'Dynamic' in Dynamic Link Libraries comes from.
| freddie1 wrote: |
|---|
| Not puzzling. Dlls loaded explicitely like that aren't loaded until the program actually runs. That's where the 'Dynamic' in Dynamic Link Libraries comes from. |
| freddie1 wrote: |
|---|
| Check that particular usage of them out. You might like it... |
thanks and have good weekend
Geez, I just sat down for a few minutes to see if I could get "Shell.Explorer" ActiveX Control (Internet Explorer) working with mingw in 64 bit and got it in about 10 minutes. That went too well! I'm posting this from that app. I want to test with VC++ yet, then I'll post it. Likely not till Sunday or Monday though.
I'm posting this code from a run of the code posted below. The command line compilation strings for 64 bit VC++ and 64 bit mingw are at top. Tomorrow I'll see if I can simplify the code somewhat by removing all the function pointer calls.
The IWebBrowser.h and Main.h files at top in the #includes are unchanged from my earlier posts of those files. This compiles to around 19 K with Mingw 4.8 x64 and 41 K with VC++ 9 (version 15) circa 2008 or so. Course, that isn't including Atl.dll which is a dependency. That file adds another 89 K. By the way, since Microsoft apparently redid that code for 64 bit (Atl.dll, that is), we can have a 64 bit version of this app. That file is simply found in C:\Windows\System32\Atl.dll.
|
|
The IWebBrowser.h and Main.h files at top in the #includes are unchanged from my earlier posts of those files. This compiles to around 19 K with Mingw 4.8 x64 and 41 K with VC++ 9 (version 15) circa 2008 or so. Course, that isn't including Atl.dll which is a dependency. That file adds another 89 K. By the way, since Microsoft apparently redid that code for 64 bit (Atl.dll, that is), we can have a 64 bit version of this app. That file is simply found in C:\Windows\System32\Atl.dll.
Last edited on
I'm really going dowm memory lane trying to remember why I did this code the way I did. I think what happened is that I really hadn't spent much time on this IExplorer example. My main thrust at the time was trying to get all the various ActiveX Controls that shipped with Visual Studio 6 (circa 1998 or so) working in SDK style API C/C++ code. My main interest at the time was the MSFlexGrid OCX (MSFlxGrd.ocx). Windows doesn't really have a grid control among its standard concrols or 'Common Controls', but the widely used MSFlexGrid ActiveX Control that mostly Visual Basic used was very widely used. If one were a C++ coder and was using MFC that environment auto-generated typical wizard generated mystery code that everybody used but no one understands. If you were an SDK coder you were out of luck though unless you could figure out how to do it. So that was more or less my starting point.
And the deal was, as I now recall (its starting to come back to me), the MSFlexGrid was a 'licensed' ActiveX Control. What that means is that if you had a developer license for the Professional or Enterprise editions, you had a license for the ActiveX Control. So it would be included in the setup program you put together for users of your programs. But someone who got a program from you which included the MSFlexGrid.ocx file wouldn't have a license. The IClassFactoryEx Interface had a special member for instantiating licensed ActiveX Controls, and that had to be used. But something about the various versions of Atl.dll was going on and I had to resort to complicated function pointer calls to get the whole thing working for both mingw and MSVC.
And when I tested the whole thing as a lark kind of for IExplorer, I just used this function pointer laden code I think. But I think it can be redone without it.
And the deal was, as I now recall (its starting to come back to me), the MSFlexGrid was a 'licensed' ActiveX Control. What that means is that if you had a developer license for the Professional or Enterprise editions, you had a license for the ActiveX Control. So it would be included in the setup program you put together for users of your programs. But someone who got a program from you which included the MSFlexGrid.ocx file wouldn't have a license. The IClassFactoryEx Interface had a special member for instantiating licensed ActiveX Controls, and that had to be used. But something about the various versions of Atl.dll was going on and I had to resort to complicated function pointer calls to get the whole thing working for both mingw and MSVC.
And when I tested the whole thing as a lark kind of for IExplorer, I just used this function pointer laden code I think. But I think it can be redone without it.
Last edited on
I have just updated the above code so as to remove all the function pointer calls and to use implicit linking of the atl.dll through the atl.lib import library. I have tested this code with VC 9 (Visual Studio 2008) x86/x64 and MinGW 4.8 x64. The libs you need to link with are ole32.lib, oleaut32.lib, uuid.lib and atl.lib. Note that if messing around with different architectures (x86/x64) you need to be very, very careful to link asgainst the correct version of the libs. If you get link errors (unresolved externals), you are linking against the wrong architecture version. This code uses my previously posted IWebBrowser.h and Main.h files. The Shell.Explorer ActiveX Control has several 'outgoing interfaces'. Another name for these are Event Interfaces. I did not include that functionality, but I can if anyone is interested. File sizes on this are about 19 K x64 MinGW and 42 K VC9 \MT (staticaslly Linked) in x64...
By the way, I fixed the issue related to the StartOLEProcess() thingie. One simply needs to put CoUninitialize() in WinMain() after the message loop so termination works correctly.
I had been having some difficulties with atl.dll in that I was receiving a message about Atl90.dll missing. I downloaded that (its about a 170 K file) and put it in C:\Windows\system32 and then it worked. That would be for x64, that is.
|
|
By the way, I fixed the issue related to the StartOLEProcess() thingie. One simply needs to put CoUninitialize() in WinMain() after the message loop so termination works correctly.
I had been having some difficulties with atl.dll in that I was receiving a message about Atl90.dll missing. I downloaded that (its about a 170 K file) and put it in C:\Windows\system32 and then it worked. That would be for x64, that is.
Last edited on
I downloaded your code, moved the header files to the folder, set linking to the libraries, and changed compiler settings, and it worked!
In my C:\Windows\system32 folder I have atl.dll, atl100.dll and atl110.dll, so one of those must have made the program work.
Looks good!
In my C:\Windows\system32 folder I have atl.dll, atl100.dll and atl110.dll, so one of those must have made the program work.
Looks good!
Glad to hear that!
I forgot to mention that for the code immediately above you can remove the function pointer declarations which I believe are in Main.h.
That Atl.lib and atl71.dll, atl80.dll, atl90.dll, atl10.dll, atl11.dll stuff I've been dealing with for years and I really don't know much about it. Conceptually, I fully understand what its doing but there are all those different versions. What seems to be happening whem one links against Atl.lib is that there are functions in there which cause those various numbered versions of the dlls to be loaded.
I code a lot in another programming language called PowerBASIC, and I can also use all that atl stuff there. In fact, that's where I first encountered it with Atl71.dll.
The situation with ActiveX Controls is that they were designed to be used in what are termed RAD - Rapid Application Development - environment such as Visual Basic or C#. What happens there is that icons representing them show up in a 'toolbox' type entity, where one can drag a control onto a visual representation of the running form/program, and the IDE will take care of all the nasty programming details of this. In such environments the necessary 'glue' code becomes invisible to the programmer, or is auto-generated and stuck in ancillary files that become part of the project but which the coder seldom if ever looks at and almost certainly doesn't understand.
That Atl stuff is a way of performing the negotiations necessary between the ActiveX Control itself and the containing application. There are about a dozen fairly complex COM interfaces that need to be dealt with that Atl takes care of.
But all this does create dependency issues when one uses atl (which stands for Active Template Librarty, by the way) to host ActiveX Controls. Its basically a story of never ending grief, it sometimes seems. Or maybe I've just never handled it well. Personal problem I guess.
But in the PowerBASIC Community the problem was solved by someone who I can only describe as a genius. His name is Jose Roca and he coded a replacement for all the functionality contained within atl.lib and all the various dlls. He provided this solution to all of us in source code form as an include file named olecon.inc (Ole Container) which we can include in our PowerBASIC projects, thereby relieving us of the burden of dealing with this atl stuiff. The final resulting executables are even smaller than their C or C++ counterparts too, considering that if one were to make an application out of this in the setup program one would need to include both the C++ executable and the atlXX.dll dependencies.
I'm working on the event interface to the above code right now. In the COM model servers such as Shell.Explorer communicate with clients through an event interface. The Interfaces involved are IConnectionPointContainer and IConnectionPoint. In all the cases I've ever seen the the type of interface used is known as a 'dispinterface'. Coding it within the client to allow the client to respond to these events is quite complex in SDK style apps. As I mentioned above, if one is using RAD design environments such as old VB 6, Delphi, .NET, or even modern C++ where one is using Microsoft's Wizard generated code to handle this, its easy. A possible downside is that the coder doesn't really understand everything going on in his/her app. But I suppose there's a lot to be said too for leveraging other peoples knowledge who provided the functionality and understand the code.
Quite a while back I posted a tutorial on using ActiveX Controls in SDK Style apps here...
http://www.jose.it-berater.org/smfforum/index.php?topic=4451.0
...where I used the MSFlexGrid.ocx file as an example. The MSFlexGrid is an ActiveX Grid Control.
I forgot to mention that for the code immediately above you can remove the function pointer declarations which I believe are in Main.h.
That Atl.lib and atl71.dll, atl80.dll, atl90.dll, atl10.dll, atl11.dll stuff I've been dealing with for years and I really don't know much about it. Conceptually, I fully understand what its doing but there are all those different versions. What seems to be happening whem one links against Atl.lib is that there are functions in there which cause those various numbered versions of the dlls to be loaded.
I code a lot in another programming language called PowerBASIC, and I can also use all that atl stuff there. In fact, that's where I first encountered it with Atl71.dll.
The situation with ActiveX Controls is that they were designed to be used in what are termed RAD - Rapid Application Development - environment such as Visual Basic or C#. What happens there is that icons representing them show up in a 'toolbox' type entity, where one can drag a control onto a visual representation of the running form/program, and the IDE will take care of all the nasty programming details of this. In such environments the necessary 'glue' code becomes invisible to the programmer, or is auto-generated and stuck in ancillary files that become part of the project but which the coder seldom if ever looks at and almost certainly doesn't understand.
That Atl stuff is a way of performing the negotiations necessary between the ActiveX Control itself and the containing application. There are about a dozen fairly complex COM interfaces that need to be dealt with that Atl takes care of.
But all this does create dependency issues when one uses atl (which stands for Active Template Librarty, by the way) to host ActiveX Controls. Its basically a story of never ending grief, it sometimes seems. Or maybe I've just never handled it well. Personal problem I guess.
But in the PowerBASIC Community the problem was solved by someone who I can only describe as a genius. His name is Jose Roca and he coded a replacement for all the functionality contained within atl.lib and all the various dlls. He provided this solution to all of us in source code form as an include file named olecon.inc (Ole Container) which we can include in our PowerBASIC projects, thereby relieving us of the burden of dealing with this atl stuiff. The final resulting executables are even smaller than their C or C++ counterparts too, considering that if one were to make an application out of this in the setup program one would need to include both the C++ executable and the atlXX.dll dependencies.
I'm working on the event interface to the above code right now. In the COM model servers such as Shell.Explorer communicate with clients through an event interface. The Interfaces involved are IConnectionPointContainer and IConnectionPoint. In all the cases I've ever seen the the type of interface used is known as a 'dispinterface'. Coding it within the client to allow the client to respond to these events is quite complex in SDK style apps. As I mentioned above, if one is using RAD design environments such as old VB 6, Delphi, .NET, or even modern C++ where one is using Microsoft's Wizard generated code to handle this, its easy. A possible downside is that the coder doesn't really understand everything going on in his/her app. But I suppose there's a lot to be said too for leveraging other peoples knowledge who provided the functionality and understand the code.
Quite a while back I posted a tutorial on using ActiveX Controls in SDK Style apps here...
http://www.jose.it-berater.org/smfforum/index.php?topic=4451.0
...where I used the MSFlexGrid.ocx file as an example. The MSFlexGrid is an ActiveX Grid Control.
Last edited on
I've finished hooking up the events interface to the WebBrowser demo. I'll repost everything, as there were changes to several of the files. First Main.cpp
|
|
Next, Main.h...
|
|
IWebBrowser.h first part ...
|
|
IWebBrowser.h Next Part...
|
|
IWebBrowser.h Last Part ...
|
|
IWebBrowserEvents.h
|
|
IWebBrowserEvents.cpp...
|
|
I had stripped all the debug code out of that, but here is the original Main.cpp where debug output is controlled by #define MyDebug. Need two posts for this...
|
|
2nd part...
|
|