I got one challenging task here.
We got one Dialog in exe file (made of C++), and now we want it to be an ActiveX control, so it could be loaded in C# .net form, However because of the complicated web of c++ header file, it's hard to pick up files to make a separate ActiveX dll.
So is that possible to export an activeX control from the exe file?
Thanks in advance.
An ActiveX control is a nothing more than a DLL. Yes it is possible to export an activeX control from an exe file. A typical scenario is to put an Image (your ActiveX control) as a Resource of another application and to extract it at runtime. Here one of the many available samples on the web.
Related
MFC projects provide enhanced support for satellite dlls which generally helps in creating localized application with multiple resources. Those dlls are called as Saltellite dlls. When program is executed, MFC automatically loads the localized resource based on environment.
If MFC does not find any satellite DLLs, it uses whatever resources are contained in the application itself. I want to know if there is any configuration setting or any other way which can help stopping MFC to load any resource specific dll.
I know that MFC tries to load resource dlls and some other initialization stuff at entry point by calling method InitInstance(). If I do not call InitInstance method, I am observing MFC does not try to load any resource specific dll. Not sure if this is right way or is there Microsoft suggested way?
I created GUI in C# as gui.dll and create C++/CLI interop interop.dll for C++ project. That means (*.exe call --> interop.dll and interop.dll call --> gui.dll) I test it with C++ console application which is working wintout any problem, because in the end consoleApp.exe and all dlls are in same folder.
What I did:
interop is c++/cli code with reference to C# dll. I created class and export it for use it inside plugin.vst3. C# dll is dynamicaly linked
inside plugin.vst3 project I includeLibrary for interop project to use class and add interop.lib to Linker. interop.dll is dynamicaly linked
What I want:
Now I want use those dlls (gui.dll and interop.dll) inside c++ project as another "dll" myPlugin.vst3 (audio plugin). For those who don't know, audio plugins are located on different location as program which use it. That means, if audio program load plugin, it is different scenario as my consoleApp.exe call dll on same location.
The Problem:
When I run host program which load my vst3, unfortunately vst3 start search for my dlls from AudioHost.exe view not from vst3 view where is my vst3 file located.
For example, if myPlugin.vst3 is inside D:\VstiPlugins\MyTest\, interop.dll is on D:\VstiPlugins\interop.dll and gui.dll next to C:\ProgramFiles\Reaper\Reaper.exe, my plugin is loaded. All files myPlugin.vst3, interop.dll and gui.dll must be on same location D:\VstiPlugins\MyTest.
The questions:
Simple question is "How to load those dlls from vst3" as I describe it in "What I want" and "The Problem"?
What come to mind as firstly was load plugin with code (like LoadLibrary(...)) instead use *.lib. But all examples and solutions, are for dlls which export only C functions and not as my scenario where I use class. Can be dll loaded from code and use class?
Another idea was DLL redirection with manifest file, but there is no documentation for that scenario or I can't find it. And I am not sure if it will be working.
I am adding functionality to an open source project which uses an external activex control known as DMGraph (http://www.codeproject.com/Articles/310494/D-Graph-ActiveX-Control-in-Cplusplus-with-ATL-No-M?msg=4567275#xx4567275xx) but I get an error that the control needs to be registered when I try opening the resource file that uses this control. As stated on the project page that I linked, there is no ocx file, but I don't understand how I'm supposed to register this control without said file. If its any help to finding the issue, I have simply downloaded the source code to this open source project that i'm trying to get this work in. It has already implemented the DMGraph functionality and works in their builds so the issue must be with trying to build it on a different machine. Any ideas?
I got the VC++ source code of a dll for a USB device project, which the deadline is close. Right now I have to call this usb dll from another VB program. But the source code is based on the template "MFC Extension DLL", which can´t be called by VB. On the other hand, "Regular DLL with MFC statically linked" can be called by programs written in Visual Basic.
Is there a way, with the least effort of modification of the source code, to be able to call this dll directly from VB?
I tried to modify the project´s configuration properties/Use of MFC to Use MFC in a Static Library. But there is build error.
Now I am modifying the source code based on the new template "Regular DLL with MFC", but there is a lot of problems. For example, I don´t know whether I can use AFX_EXTENSION_MODULE in my new dll code.
Your problem is likely due to not implementing a CWinApp derived object which provides services that the MFC classes in the DLL rely upon. Probably you can just bung one in and it will work.
See here for more information:
http://msdn.microsoft.com/en-US/library/h5f7ck28(v=VS.80).aspx
So i have the misfortune of embedding this proprietary ActiveX control we created into a web page so that it downloads the code from our server and installs as necessary.
Our ActiveX requires a host of other files which need to be installed along with the activex control itself. It should also be noted that the activex and all its dependencies are c++-based COM objects (many use MFC).
So I read this article about it:
http://msdn.microsoft.com/en-us/library/aa751974(VS.85).aspx
But it leaves a lot of things unanswered. For one thing, my ActiveX is actually embedded in a DLL file that contains other COM interfaces. Also, is it possible to have the mentioned cab file include the ActiveX/SDK installer and run that if the GUID isn't present? For example:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
Setup.exe=Setup.exe
[Setup.exe]
file-win32-x86=thiscab
run=%EXTRACT_DIR%\Setup.exe
Security is not an issue here as this is an intranet-based solution (not available publically).
Also, the article mentioned here seems really old. Is there more up to date info available?
You can create a dependency between the installer and a dll that is on the system like this:
[Add.Code]
Your-dll-name
[Your-dll-name]
Version=Your dll version
hook=setup.exe
[Setup.exe]
file-win32-x86=thiscab
run=%EXTRACT_DIR%\Setup.exe
If the system cannot find your dll or the version is lower, then it will run the setup.exe that suppose to install and register the dll.