I have a native target application that renders something by using Direct3D11. I want to extend the functionality of the target by injecting a DLL and hooking some APIs(not important to mention but it is XInputGetState). When DLL is injected, it also creates a window and provides some useful information. To render the information in the window, I use Direct2D, but after injecting the DLL, in another process's address space, calling the ID2D1Factory::CreateHwndRenderTarget fails with the error code D2DERR_NO_HARDWARE_DEVICE and doesn't create the ID2D1HwndRenderTarget object. The Factory object is created successfully and it is not NULL.
When I change the project type from Dynamic Link Library(.dll) to Application(.exe) and the entry point from DllMain to main and run it as a separate console application, the ID2D1Factory::CreateHwndRenderTarget succeeds.
I think that the problem causes by the existence of a created Direct3D11 Device already, but I am not sure.
Is there documentation about that? How can I solve the issue?
Put directly the D2D creating function into new thread by CreateThread in DllMain.
Related
When using Win32 API, it's not really necessary to have a winmain entry point in order to create a window, because we can still call RegisterClassExW and CreateWindowExW, etc. I wonder if it's possible to do so as well in creating a C++/WinRT window, since almost every example on the Internet is using template projects.
I tried to create a struct which inherits implements<App, IFrameworkView, IFrameworkViewSource> with all necessary functions (Initialize, Uninitialize, Load, SetWindow, Run, etc.), then call CoreApplication::Run(winrt::make<App>()) inside int main(), but WinRT either complains about not having run init_apartment() beforehand, or shows a weird error as WinRT originate error - 0x80070057 : 'serverName' and that HRESULT is E_INVALIDARG, and that a hresult_invalid_argument(take_ownership_from_abi) is thrown. Plus, the source file created with template project doesn't even have to run init_apartment() first, which I couldn't really understand why.
Is it possible to create a C++/WinRT window from a console application? Thanks.
No.
UWP console apps may not create a window. They cannot use MessageBox(), or Location(), or any other API that may create a window for any reason, such as user consent prompts.
https://learn.microsoft.com/en-us/windows/uwp/launch-resume/console-uwp
I have developed a MFC ActiveX control, that displays a graph using data retrieved from Kepware OPC Server using OPC Client. OPC Client code is part of ActiveX control code. The OPC client is launched in a separate thread from main control thread. The control works well when there is only one instance of it on the MFC dialog. However if I add another instance of it on same form, the curve on the graph starts malfunctioning. From the logs I can see that Control app class which is ultimately derived from CWinApp is instantiated only once. Any ideas why it is messing up? Are any global variables being shared between two instances? I am using Visual Studio 2008.
If your ActiveX control is located inside a DLL this DLL is always loaded once into the process that uses the ActiveX control. So it is normal that you only have one CWinApp object even if you have multiple controls.
So you need to design your object in a way, that global data inside the DLL doesn't affect the behaviour or data inside a control instance.
I suppose that you have some global data, that is used by the first control. And when another instance is created this global data is modified by the second instance and the first instance shows wrong data or misbehaves.
All state of such an ActiveX must be located and allocated inside the object.
I am working on MFC solution that consists of many projects. One of my projects "App.exe" depends on other project output dll "SC.dll".
I added reference to the other project via Add Reference option under the App project.
I want to "based on an option" switch between languages by using resources dll.
I've another resources project that produces Arabic resources "SC_AR.dll".
I tried to use LoadLibrary based on the option ,but it failed.
Is the "Add Reference" approach is wrong?
If not, how I could switch between the Dlls?
If yes, what is the right approach to follow?
There is no need to reference a resource satellite. MFC searches satellite DLLs using the user's Windows UI language and your application's file name. To switch to another satellite, call LoadLibrary() and then call AfxSetResourceHandle().
Of course, this is assuming you are loading all resources via MFC (e.g. use CString::LoadString instead of LoadResource ). You have to use your own satellite DLL handle explicitly if you call API directly.
PS the less said about SetThreadLocale the better.
If you're using MFC then the resource dll is loaded in the boilerplate that's generated in the main file. (can't rememebr it offhand) but search for LoadResource(). You'll have to call LoadLibrary to get the hmodule to pass into this.
Be aware that if you're displaying resources from several dlls, you will have to be careful about dialogs in a different resource dll. If youre simply swapping dlls, you won't have a problem.
As MFC doesn't support Arabic, I made an English dialog and Arabic one inside the dll. And according to the Language property I send the resource ID to the Constructor of Dialog.
And for any String I use LoadString
I have an ActiveX dll that loads a child dll (NPAPI plugin). My child plugin creates multiple threads and they need to communicate back to the web page. In my ActiveX (parent dll) I have connection points to fire an event for javascript to provide updates. The problem I am having is that I do not know how the child can call the parent DLL.
What I have tried:
1: Passing a function pointer to the child dll of a function that is not within the class and used a global variable that is a pointer to the ActiveX class (this), but the connection point fails when Invoke with E_UNEXPECTED
2: Passing the child dll a pointer to my class function, and get the same results.
Im still learning C++ and COM at the same time, sorry for my ignorance. Thank you.
COM has ways to set things up so that you can call COM methods from other threads, but the easiest way for you to do this would be to make all calls back to the activex control on the main thread. One way to do this is to create a Message Window and post a windows message to it with the LPARAM being a pointer to a data structure containing the parameters needed to make the call; you create the structure and fill it out, then post the message and free the memory after your WINPROC has made the call.
FireBreath uses this approach and it works quite well. Speaking of which, have you considered implementing your NPAPI plugin as a FireBreath plugin so that it works in both activex and npapi?
Here are some code samples that may help:
WinMessageWindow (.cpp, .h) - this is a class FireBreath uses for creating message windows; pay particular attention to the DefaultWinProc which is used as part of an async (often cross thread) function call
NpapiBrowserHostAsyncWin (.cpp, .h) - this is a class used on some browsers for the npapi plugin to work around NPN_PluginThreadAsyncCall not working. It utilizes WinMessageWindow to make cross thread calls in _scheduleAsyncCall
Hope that helps
I would like to have the ability to process Win32 messages in a console app and/or inside a standalone DLL.
I have been able to do it in .NET with the following article and it works great in C# inside a console app and standalone DLL
http://msdn.microsoft.com/en-us/magazine/cc163417.aspx
Is there a way to do the equivalent with C/C++ Win32 APIs? I have tried doing RegisterClassEx(...) and CreateWindow(...) even passing in HWND_MESSAGE to hWndParent but the trouble is that after the "invisible" window is created messages are not being processed probably due to the lack of a message pump.
Where would the message pump go if you had a DLL entry point? I have tried creating another thread in a DLL and put while(GetMesage(..)) there but that did not work either.
Any ideas?
You need a message pump yes. The window also has thread affinity so it needs to be created on the same thread that you're running the message pump on. The basic approach is sound, if you include more code it may become clear what the problem is.
In addition to what Logan Capaldo said, you also have the problem that, as a DLL, you don't know at compile time what kind of process is going to be loading you at runtime.
If you are being loaded by a console application (/SUBSYSTEM:CONSOLE), then creating a hidden window of your own and setting up a message pump on that same thread will work fine (as long as you are the first window created).
If you are being loaded by a windows app (/SUBSYSTEM:WINDOWS) then you might run into problems getting messages. They will be sent to the top-level window in the hierarchy, which you didn't create. You'll need to get the hWnd of the main process and subclass it (if you aren't already).
If you are being loaded by a service, then you aren't going to get window messages at all. You instead need to use the RegisterServiceCtrlHandlerEx Function