C#, MFC, ATL, and Scripting
Wow. I didn't realize how hard it would be to create a wrapper for OpenFileNames. I know it would take me about 5 minutes to code in C# or VB... but getting C++ COM stuff right so that it shows up with VBScript scripting is a real PITA (IMHO).
I started out thinking I would write a C# COM component (research pointed to this and this). After it didn't work on the first try... and thinking about the ramifications (mainly a .Net framework requirement for using a simple website), I felt that it would be better to code it in a nice, simple, small C++ DLL. It should be just a few lines of code, right?
Well, I wrestled with MFC to create the COM component (research)... and finally gave up when I couldn't convince MFC that my methods really should be made public.
I switched to ATL on the advice of Brent R., which was probably a good idea in the first place (more lightweight, less dependancies, etc). After doing a bit more research, I'm very close.
I spent an hour or two sidetracked on an issue that ended up being a part of my test script, which occurred when I migrated from JavaScript to VBScript because of a lack of support for [out] or [in, out] parameters in JavaScript. Now, I've just discovered that both JavaScript and VBScript reall do support output parameters... just as [out, retval].
I'll share my code (if possible) when I get it working. Right now I have a compiling COM DLL that is exposing itself perfectly, and script that can call it just right... but nothing is wanting to return (probably a problem in handling variant/BSTR conversion).
So... yeah. I'm more a C++ newb than I thought. I only take comfort that I do know how to code (just in other languagse), and I will get better in this arcane language (which is more figuring out how to work with, rather than against, the templates). And once I "master" C++... well... I've been wanting to pick up assembly and Cg. :)
Comments
- Anonymous
January 09, 2006
Why not create a .NET assembly in C#, then use COM Callable Wrappers to generate a COM interface? - Anonymous
January 10, 2006
Well, one of my smaller concerns was that I couldn't be sure that everyone internally would have the right version of .Net. I have been bitten by this before (for example, newer(now released) versions of .Net had more strict validation of stream data for de/encryption, and would fail on code that used worked on older .Net clients).
In the end, my main concern was requiring .Net just to use a simple website... that seemed like overkill to wrap a single Win32 function.