robert_brewington wrote: > After several hours of playing around, I am beginning to get a grasp > of what is going on. > > Apparently, Microsoft is trying to get rid of the venerable MFC tools > (which is what I used to use). Unfortunately, those pesky programmers > seem to want to keep using it. So, there is now something called > Common Language Runtime (CLR) which I guess is supposed to replace > MFC. Or, maybe this has to do with the .NET aspect, I can't see that yet. > > Unfortunately, Visual Studio Express (free version) only comes with > CLR support for creating UI stuff. Apparently you have to pay the Big > Bucks for the Professional Version to get MFC. So, when I create my > Settings dialog VS forces it to be CLR. Thus, within my Settings code > the System:: style call works. > > My DLL main code (Brew.cpp) is not configured to use CLR. Thus, the > Windows form of the MessageBox works. The CLR access (which requires a > number of changes to the Properties of the .cpp file) allows the use > of the System:: type of calls. > > So, I tried an experiment - I changed the Brew.cpp file to compile > using CLR. Compiles and builds fine - unfortunately, the main program > from the outside vendor that accesses the DLL then fails - it main > does not support the CLR format. > > So, the question becomes - how can I mix and match non-CLR and CLR > routines? Brew.cpp MUST be non-CLR to work with the main program. > Including the Settings.h (CLR format) in the Brew.cpp code causes the > Brew.cpp to fail compilation. How can the Brew.cpp call things in > Settings? > > Lost in the woods, > brew
<smacks head on keyboard> 76yuh (literally) Now I know why _T() isn't available. MFC isn't available in VS _Express_ 2008. I feel really dumb right about now. Visual C++ has two different compilation modes: Native and Common Language Runtime (aka .NET). This list is generally only useful for VC++ _Native_ code. Most of us have never touched .NET. Of those of us who have (not me - I've seen some .NET code but have never had to touch it), fewer have had to write "Unmanaged" code. In general, .NET code is written in a .NET-specific language such as C# or VB.NET. However, let's say you have a DLL named brew.dll. 'brew.dll' is code that, assume for the moment, the source code is unavailable and was written in an unknown language. Basically, the point of the VC++ CLR .NET integration libraries is to take an unmanaged binary DLL and create a managed wrapper. Basically you import the functions you want to use (i.e. write some C++ code to interface with the DLL) and then use the integration library to convert variables and return values into .NET-friendly variables and return values. Basically, the resulting .NET DLL acts as middleware for brew.dll. Then, from the .NET language of your choice (e.g. C#, VB.NET, etc.) you call the middleware .NET DLL (i.e. 'import' it or something like that) and then the function calls you created inside your .NET DLL are available to the .NET application. Evil. In short, you don't want to go there. BTW, MFC has never been free - the Express edition is a severely cut down version of the full suite but good enough for most beginning programmers which is why we recommend it. Since you want to do advanced stuff (i.e. GUI stuff) but don't want to pay for MFC, things get tricky. You could do the .NET route but we can't really help you if you go there. If you do want to go the .NET route, I recommend visiting the folks over at www.codeproject.com. You could obtain the full suite (expensive, but if you need to do MFC, ATL, or COM, it is really the only way to go). You could switch IDEs (this is a "tossup" - wxDev C++ might be worth looking at). Or you could try working with the wxWidgets toolkit. The latter would allow you to keep the IDE but AFAIK, there is no "GUI designer" plugin tool for wxWidgets for VC++ - and if there is, it probably doesn't work with Express (Microsoft takes legal issue to people making plugins that work in Express). You _COULD_ do the GUI design in wxDev and then bring the generated code into VC++ Express and build the code there. Massively evil workaround for staying in pure Win32 and VC++ but that's the most financially affordable combination I can think of off the top of my head. I recommend staying in VC++ because the debugger is far superior to wxDev's debugger. Although, assuming nothing is name-mangled in brew.dll, you might be able to get away with doing the GUI portion of the code and build that in wxDev and just build brew.dll in VC++ (if you've got that working already - I see no reason to change that part of it). It is a tough call to make but those are a few ideas worth considering. Weigh these options. I've laid out the pros and cons. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* MyTaskFocus 1.1 Get on task. Stay on task. http://www.CubicleSoft.com/MyTaskFocus/
