Does the window class name you specify in lpszClassName ever change? E. g. for applications like firefox? Or is that name always the same for an application? SO once I installed Firefox, I can be sure that its classname doesnt change?
Thanks!
The only way you can guarantee the class doesn't change is with some promise from the application developer. For example Winamp guaranteed its window class so you could use FindWindow on it for automation.
But there is nothing stopping an application from using a different class name for every window it ever creates.
Note that if you are trying to automate external applications, window class name is only one of countless moving-target problems. For example you get the window handle via FindWindow. You send it a WM_COMMAND for some command ID you found. Next version the application changes this command's ID. Same issue.
Related
i have simple video player.
https://github.com/sailfish009/sample_video
now i want to port it to windows template library 9.1.
Edit: solved, CWindowImpl's handler compatible with CWnd's.
//screen = SDL_CreateWindowFrom(this->m_hWnd); //HWND from CWnd previous working code
screen = SDL_CreateWindowFrom(m_hWndClient); //HWND from CWindowImpl
The question is asked incorrectly. You don't look for compatibility, you just look for a way to access HWND window handle.
No, the classes are not compatible and more to that they are different conceptually. In ATL/WTL CWindowImpl is a class that implements a window procedure. Such procedure is typically a static function, and the helper class does the job of "attaching" it to C++ class, connects it to specific thin window wrapper such as CWindow, offers easy way to connect message handlers etc. m_hWndClient is not even a member of CWindowImpl and belongs to WTL frame window related classes.
I am developing firefox extension.
Problem is that when i open second window (Ctrl + N) my extension has new state for new opened window.
If I reacts or changes on second window it never affect on first window or vice versa.
Ex
Installed extension on Firefox
first window opened. My extension proper functioning, change state, login, view data etc
then opened second. My extension goes new state I cant get previous states (first window states).
How can maintain same state between first and second or other firefox opened windows.?
Am I correct to assume you're developing a XUL overlay add-on, and not an SDK add-on?
One way to share state between windows is to use Javascript code modules. A code module will only be loaded once (unless explicitly unloaded) and therefore will expose the same data to multiple windows. Be sure to read the "Sharing objects using code modules"., However, please note that therefore when closing a window, any state associated with it and stored within the code module must be cleaned up, or would leak otherwise.
If you're using the SDK instead, your main.js module is already the equivalent of a code module. Content scripts may use message passing to store and retrieve state from your module.
Thank you for reading at first.
I designed a WPF application which rehosted the Designer, Toolbox and Properties of Windows Workflow. My Idea is really simple that I just want have visualization at runtime about my workflow and design them in the runtime as well.
ISSUE:
Now I try to Invoke a Method of a class under the same namespace of whole application. The class is called MyTwsClass. Please have a look below:
It is extremely Simple. The TwsClass is from a Reference ActiveX of Interactive Brokers Trading Software. This ActiveX simply provide the method and event for you to communicate with your account. Alright, I implement the MyConnect() method as you can see and this method simply set up some string and int variables to be parameters of connect method from TwsClass. I noticed that I could not set MyTwsClass or MyConnect method as static.
Now, at runtime designer, I try to invoke the MyConnect method. First of all, picture below:
Since MyTwsClass could not be a static class with static method (I guess it is because it inherits from the ActiveX class TwsClass, I am not sure as a newbie.) So I wanna invoke the instance method. It has no complaints before running the workflow. After running this, I expect that I should be able to connect to the API of the trading software.
Now I run the workflow:
Right after clicking the running button, it runs and I got pop up window to tell me that APP has crashed with exception code C0000005. If I click the close option, my WPF application will be closed. BUT before I close it, I could see that ACTUALLY the crashed WPF actually connected to the API as you can see in picture above to tell me that 1 is connected......
I tried my best to check this problem on Internet. I am kind of have sense that it is all because of some issue within Interop or COM process between my WPF and the reference ActiveX as the crash window indicated that the TwsSocket.dll is the reason.
But I really could not figure out further.....
Due to the recently added "feature" in IE8 where new windows are automatically associated with a single session, some of our code is behaving erratically.
This is because a separate app would launch a new IE window when it was activated, and once the user was finished, close the window. This worked fine in IE7 because the session information in the windows stayed separate. However in IE8, since the session is shared among IE windows, we find that the "pop up" app would corrupt the session on the first app.
I have read about the nomerge switch, so that is a workaround, but I was wondering if there was a way of working the solution into the "CreateObject" of vbscript; i.e:
Dim ieWin As Object
Set ieWin = CreateObject("InternetExplorer.Application")
Is there a way of sending parameters when calling the CreateObject function?
No, there's no way to use COM to create an IE instance that specifies this behavior (or any of the others, e.g. InPrivate, No Add-ons, etc). The only thing you can do is create an automation instance that defaults to MediumIL using the CLSID provided for that purpose. http://blogs.msdn.com/b/ieinternals/archive/2011/08/03/internet-explorer-automation-protected-mode-lcie-default-integrity-level-medium.aspx
If you have control over the web application you are loading with your IE window you can set it's session to "cookieless" (http://msdn.microsoft.com/en-us/library/aa479314.aspx) which will avoid the issues you're having with multiple instances.
The solution we ended up going with, although it's more a work around than anything else - was assigning a new url to the popped up window.
Previously, it worked as follows:
Call centre agents would be using our internal app for other duties
e.g. "http://internalsite/somepage.faces" on a day to day basis.
When they got a phone call, a third party app would fire up
"http://internalsite/customerdetails.faces". This caused the issues mentioned above.
The solution we went with:
We assigned "http://internalsite/customerdetails.faces" it's own url e.g."http://customerdetailminisite/customer.faces".
This way the call center agent could keep their main window open for other stuff and still be able to handle calls when they came in.
I have developed a COM component (dll) that implements an Edit() method displaying a WTL modal dialog.
The complete interface to this COM component corresponds to a software standard used in the chemical process industry (CAPE-OPEN) and as a result this COM component is supposed to be usable by a range of 3rd party executables that are out of my control.
My component works as expected in many of these EXEs, but for one in particular the Edit() method just hangs without the dialog appearing.
However, if I make a call to ::MessageBox() immediately before DoModal() the dialog displays and behaves correctly after first showing the MessageBox.
I have a suspicion that the problem may be something to do with this particular EXE running as a 'hidden window application'.
I have tried using both NULL and the return value from ::GetConsoleWindow() as the dialog's parent, neither have worked.
The dialog itself is an ATL/WTL CPropertySheetImpl.
The parent application (EXE) in question is out of my control as it is developed by a (mildly hostile) 3rd party.
I do know that I can successfully call ::MessageBox() or display the standard Windows File Dialog from my COM component, and that after doing so I am then able to display my custom dialog. I'm just unable to display my custom dialog without first displaying a 'standard' dialog.
Can anyone suggest how I might get it to display the dialog without first showing an unnecessary MessageBox? I know it is possible because I've seen this EXE display the dialogs from other COM components corresponding to the same interface.
Are you using a parent for the Dialog? e.g.
MyDialog dialog(pParent);
dialog.DoModal();
If you are, try removing the parent. Especially if the parent is the desktop window.
Depending on how the "hidden window" application works, it might not be able to display a window. For example, services don't have a "main message loop", and thus are not able to process messages sent to windows in the process. i.e, the application displaying the window should have something like this:
while(GetMessage(&msg, NULL, 0, 0))
{
if(!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
in WinMain.
This isn't supposed to be reliable - but try ::GetDesktopWindow() as the parent (it returns a HWND).
Be warned - if your app crashes, it will bring down the desktop with it. But i'd be interested to see if it works.
It turns out I was mistaken:
If I create my dialog with a NULL parent then it is not displayed, and hangs the parent application
However if I create my dialog with ::GetConsoleWindow() as the parent then the dialog is displayed; it just fooled me because it was displayed behind the window of the application that launched the parent application
So now I just have to find out how to bring my dialog to the front.
Thanks for the answers ;-)
Whatever you do, do not use the desktop window as the parent for your modal dialog box.
See here for explanation: http://blogs.msdn.com/b/oldnewthing/archive/2004/02/24/79212.aspx
To quote the rationale:
Put this together: If the owner of a
modal dialog is the desktop, then the
desktop becomes disabled, which
disables all of its descendants. In
other words, it disables every window
in the system. Even the one you're
trying to display!