I have inherited an old C++ (MFC) project and will have to add new functionality.
The new functionality will mostly not conflict with the existing C++ code, like additional dialogs etc.
Having limited experience with C++ MFC, I would very much prefer to do the additional functionality in Delphi, create a DLL and use the DLL in the C++ project.
I guess this is generally possible, similar to using C++ DLLs in Delphi?
Are there limitations on what can be done this way?
Basically, there are no issues. But if you're going to use dialogs and so on, your application will be using two frameworks, MFC and the VCL, and they may not play very well together.
Delhi if I recall my history should create Dll's happily. See here 'Calling delphi DLL from MS Visual C++' for an example
Related
I am trying to add an unmanaged C++ dll to a managed (CLI) C++ dll project. When I click the "class wizard," I get a "MFC classes can only be added to MFC projects" error message. I am not using MFC, to the best of my knowledge (Use of MFC is blank under my unmanaged dll's project page). Is there another way to add an unmanaged dll to my managed dll's project?
For anyone who is interested, I've thrown the rared solution up on my DropBox account: https://dl.dropbox.com/u/98752313/CplusplusArrayTest.rar
I realize there are far too many settings that could be wrong for me to simply copy and paste everything into the available space.
There are three projects within this solution. CplusplusArray (should be complete, it's the unmanaged .dll), ManagedCpluspplusArray (need to add the unmanaged dll, and modify a few things, it's the managed .dll), and a C# test program (not written yet, will hopefully talk to the unmanaged dll through the managed dll).
The whole goal of this project, if you are wondering, is to give C# the ability to use arrays with longs as the indexers. If you've used any amount of .Net before, you may have run into the Int32/Uint32 limit on the size of objects in the CLR. I am hoping to get around that by implementing the array in C++ land, then modifying / compiling some Mono Collections.Generics classes against it, thus giving us some breathing room. The reason I am doing C# -> C++/CLI -> C++ is so that, according to my research, we can use object oriented code with it; the DllImport stuff works fine for C-like functions only, and I want to preserve OOP, rather than modify things to work C-like. Since arrays are the building blocks of the List / etc. classes, from what I can tell, of the Collections namespace, getting just them to function in 64-bit land will give us everything else.
You need to add a new project, not a new class. Once you "Add Project", you will be asked what type of project you want to add, and a plain C++ DLL will be one of your options.
Once you have both projects in your solution (a C++/CLI DLL project, and a C++ DLL project), you can go to the workspace dependencies and indicate that one of them depends on the other.
Additional notes:
The Class Wizard is all about adding MFC classes. Because you're not interested in adding MFC classes, this is not the right tool to use.
When I have written a C++/CLI DLL that utilized a native C++ DLL, I needed to add instructions to link to the C++ DLL's import library. This was configured in:
"Project Properties > Configuration Properties > Linker > Input > Additional Dependencies"
The workspace dependencies guarantee that the unmanaged library is built first, and that if the unmanaged library is updated, the managed library will be recompiled or relinked if needed.
I have a visual studio 2005 c++ project (that uses QT framework). I would like to reference and use a .net 4 library that I have via COM. I know that if I have a .net project (.net 2 or .net 3.5) in 2005, I cannot reference the .net 4 library but I am curious to know if I would have any issues trying to use it in a c++ project thru COM. I'm not at a point were I can create and test a proof-of-concept application yet so I was wondering if anyone else has tried this or know anything about it.
Thanks
Using COM is a fine way to get the CLR loaded so you can execute managed code. But you'll have to use COM programming techniques in the C++ code. Using Add Reference doesn't work, that's a option that's only available if you write managed code in the C++/CLI language.
One good way is to use the #import directive in your C++ code. That can load a type library and auto-generates smart pointer types and method wrappers that you can directly call in your C++ code. Generate the type library you need with the Tlbexp.exe utility or the Regasm.exe /tlb command line option. QT has built-in COM support as well, I don't know enough about it.
Our VB6 program currently calls code in a C++ dll. This dll does not need to be registered, it only needs a .def file specifiying the properties and methods. Vb6 late binds to it. The dll is written in VS2005 without a dependency on the Net framework.
As we are migrating our application to Net4 and also want to enhance the C++ dll with new functionality, I was wondering how to migrate the existing C++ code to VC++. I suppose thereafter the dll will just happily integrate in our solution which already contains C# and VB.Net libraries too.
Is there some tutorial/documentation about the do's and don'ts of this plan?
EDIT:
I think I have some basic misunderstanding about VC++, thinking that it can be ported to 100% managed code while keeping the C++ syntax. The replies I get seem to indicatie that VC++ will always produce native, unmanaged code?
From a pure C++ point of view, you should be able to convert the VS2005 solution and project to VS2010 automatically. If I recall when you load the solution or project into VS2010 it will automatically convert it for you.
If you open the VS2005 project file in VS2010, VS2010 will automatically convert the old project to the new project format and the auto-conversion will do it's very best job to get everything correct. This usually works, but not always. So the moral of the story here is, double-check all of the new project's compiler/link settings, to be on the safe side.
Also with VS2010, you have some better interop possibilities between managed and native code: P/Invoke and C++/CLI. P/Invoke is simpler, but you will find that stuff may compile but fail at runtime. C++/CLI is way more flexible, a bit more work, but makes it much easier to debug the interop, when it becomes necessary.
I'm developing a C++ application that needs a GUI. I would like to use the Windows 7 Ribbon Framework, so I'm not interested in having my app compatible with OS different that windows. I would like to also use my preferred IDE, Visual Studio 2010 and obviously I would like to use standard C++ things like std::string, etc. I saw that there is Qt, it seems cool but as I understand I shoud use it with their own compiler because they provide some things that are not part of the standard c++ (slots keyword for example). Plus, I saw that I can use a QWinHost to host win32 controls but I'm not sure if I can host the ribbon control. Should I implement myself a little library to simply manage native win32 controls or should I go with Qt?
but as I understand I shoud use it with their own compiler
Nope, that's incorrect. You'll use your compiler - be it microsoft compiler, mingw-g++ or something else, as long as it is supported by Qt.
Qt provides their own additional preprocessor, called moc. Moc takes input files and based on their contents produce additional *.cpp files which contains standard c++ code. Those files are in turn fed to your "normal" compiler. All necessary build rules are handled automatically, as long as you use qmake to generate project.
Should I implement myself a little library to simply manage native win32 controls or should I go with Qt?
It is your code, and your decision to make. However, to me writing "little library" sounds a lot like reinventing the wheel. If I were you, I'd first tried to make the control work with Qt - because this way I won't have to reinvent the wheel - there are too many GUI toolkits already, so making another one alone is quite pointless.
I'm going to create a utility with GUI that will run on Windows operating systems.
It should require minimum (or zero!) amount of additional libraries, files or DLLs to run because it will be executed from an installer. Because of this, i don't want to use .NET for it will require user to install .NET Framework. I know today, most of Windows installed system come with .NET Framework but in my case i cannot be sure.
The utility will...
send some data to a web site and
parse the returning data,
collect some hardware info, like MAC address,
CPU type and make, hard-disk serial
number
I suppose native Win32 API could be used for all of those above, but instead of hassling with Win32, i'd prefer using a more developer friendly API, or SDK.
Thanks in advance.
Win32 API is the only way, and of course there are standard API - for sending data over the internet, you could use WinInet.lib/dll, to obtain information about the MAC, you could use the GetAdaptersInfo by using Iphlpapi.lib/dll,(here's a link on how to use it) for the Hard disk serial number you could use GetVolumeInformation by using kernel32.lib/dll. For the CPU Id, you might look into GetSystemInfomation
Edit: There's a C++ code, but you can easily derive a wrapper from this site Unfortunately, with WinAPI is not easy, no such thing as RAD with WinAPI but what you gain out of it is lightweight code instead of relying on SDK's, frameworks and dragging buggy dll's around with your application.
Hope this helps,
Best regards,
Tom.
You can statically link most C++ GUI libraries - even MFC. Personally, I recommend WTL, wihich is very light and header-only.
If what you want is minimum dependency with external files or DLLs you could statically compile all the required DLLs with the tool exe. Then you could use something like Visual C++ to develop such tool.
WTL is perfect for this sort of application and I am surprised more people aren't recommending it. You can also statically link with the CRT and hey presto - no dependencies and a very small EXE.
Delphi (now by Embarcadero) would do the job, creating a .exe file with no dependencies, and it is much easier to work with than the raw Win32 API.
If you don't like Object Pascal, you could try C++ Builder instead.
For the GUI you can either build your application with MFC (statically linked) or use a HTML based dialog that you can interact with using COM. (It is even possible to interact with javascript present in the page displayed by the dialog).
For the specific requirement that you do have, I feel Win32 API is the only way out.
Use MFC and statically link to it. No runtime dependancies need to be installed.