I have multiple firefox profiles running each with multiple windows.
When I pick a random window from each profile and run this code on that windows hwnd it sets the icon for all windows in that profile. SetClassLongPtr(targetWindow_handle, GCLP_HICONSM, ctypes.cast(hIconSmall, ctypes.uintptr_t));
I was wondering how to get this class?
I tried using GetClassName on all window handles however that returns MozillaWindowClass for all windows regardless of profile. Yet SetClassLongPtr does not apply across profiles, so that's how I know that the class of windows in first profile is different from class of windows in second profile.
Private window classes are registered per-process. So whilst each of your windows used a window class with the same name, those names are defined relative to a per-process namespace. So, the window class with name foo in process A is a different window class from that named foo in process B.
From this knowledge, and the facts you report in the question, it would appear that Firefox uses separate processes for distinct profiles. But I could well imagine that different versions of Firefox behave differently. That seems to me to be an implementation detail that you should not rely upon.
Related
In a Delphi 10.4.2 win-32 VCL Application associated with graphic file formats in Windows 10, I get parameter files selected in Windows File Explorer. Here I watch the files passed to my app right after Application.Initialize;:
CodeSite.Send('AppInstances: ParamCount', ParamCount);
When I select ONE file in Explorer and then press the ENTER key, this file gets loaded in my application. So far so good.
But when I select THREE files in Explorer and then press the ENTER key, my app gets started THREE times each time with ONE of the 3 file parameters:
Is it possible that Explorer would start my app only ONCE and pass the 3 selected files at once to my app when I press the Enter key?
On Windows 7 and later 1, you can register a MultiSelectModel value (either Document or Player) with your file association verb(s) in the Registry. This is the easiest way to allow Explorer to send multiple files at a time to a single instance of your app, such as in separate command-line parameters.
1: I don't know exactly when this feature was first introduced.
Prior to MultiSelectModel, other ways to handle this included:
implementing the IDropTarget interface in your app, and then registering the DropTarget with your file association verb(s). The Shell can then construct an IDataObject containing information about the files(s), and pass it to your IDropTarget implementation (also see this article). This is the preferred method, as it does not suffer from limitations that other methods have (including MultiSelectModel!), and it allows for more flexibility as the same IDropTarget implementation can accept multiple files executed in Explorer, files dropped onto your app's window, even dropped onto the app's .EXE file itself. It is just a matter of registering the same IDropTarget with the appropriate APIs.
Implementing a DDE server in your app, and then registering the server with your file association verb(s). The Shell can then start a DDE conversation with your app and send the file paths over to it using your specified command(s).
just accepting the Shell starting a separate process for each file. Before your app creates its UI, have its startup code check for a file path on its command-line, and if found then look for another instance of your app already running, and if found then use an Inter-Process Communication mechanism of your choosing (ie, WM_COPYDATA, named pipe, socket, mailslot, etc) to send the file path to that existing instance, and then exit.
I know it's possible to take a dialog that you built yourself and parent it on another form. But is it possible to parent a standard Windows system dialog on a form that you designed?
Specifically, I'm trying to set up a form with multiple tabs that provide different ways to obtain a reference to data used by the program. One of those tabs should represent the file system, and the ideal way to do this would be with the standard Open dialog that can be instantiated with the COM identifier CLSID_FileOpenDialog.
Is there any way to take a system dialog and cause it to appear parented on another window, without the border, title bar, etc?
There are ways to use a hook, either via SetWindowsHookEx() or SetWinEventHook(), to grab a system dialog's HWND, then you can do whatever you want with it, such as call SetParent(). But just because you CAN does not mean you SHOULD. System dialogs are designed to run as their own windows, not embedded in someone else's window. A better solution might be to use the same Shell display components that are used by Windows Explorer (and system dialogs) via IShellFolder::CreateViewObject() or SHCreateShellFolderView(), or find a third-party solution that does the hard work of interacting with the Shell for you.
I have an application and would like to know what GUI toolkit was used to implement it. The list of DLLs which it uses at runtime wasn't very enlightening, I didn't recognize anything. Tools like Spy++ or UISpy show that the windows have class names like wcl_manager1 (apparently toplevel windows) or wcl_internal_window_class (for anything else). Most of the controls (line edits, check boxes, buttons) don't even have a native window, i.e. no HWND associated.
Does anybody know what GUI toolkit this might be?
Look up ProcessId property and you'll figure it out.
In my case it was CiscoJabber.exe with "20200" window name.
I want to use the function "findwindowex" (windows API)
I wanted to know what appropriate values for the parameter "ClassName".
Are the tables that are here show the possible values?
If not - where can I find details of all types "ClassName"?
(Am I understood? I do not know good English.)
No, those are the names of some classes registered by the system. A great many Windows applications will be built with classes registered by those applications.
If you wish to find the name of the window class used by a particular window, use GetClassName().
You need to use a tool like SPY.EXE that's included somewhere as part of the win32 SDK. It shows the classname of the window currently under your cursor.
Microsoft Spy++ I believe when you hover over the window after clicking the Find button it shows all the information about the window.
The Qt documentation for QWidget::activateWindow() states:
On Windows, if you are calling this
when the application is not currently
the active one then it will not make
it the active window. It will change
the color of the taskbar entry to
indicate that the window has changed
in some way. This is because Microsoft
does not allow an application to
interrupt what the user is currently
doing in another application.
However, Skype appears to defy this rule. If Skype is running but is not the active application, I can launch it from the start menu and it brings the existing instance to the foreground, activates it and grabs input focus.
And how can I do this?
(NOTE: This is specific to how QtSingleApplication works)
The solution is stupidly simple for my issue. Simply call AllowSetForegroundWindow(ASF_ANY); at the beginning of the application, and the original process will thus be allowed to bring itself to the foreground by use of SetForegroundWindow(). No strange hacks, just one line of code to add and no need to modify QtSingleApplication either.
I don't think you can do it reliably with the Qt API alone.
There are multiple solutions for windows. E.g. here, and here, and here.
The method I've used before is to declare a shared memory section, and write the application's window handle there. Later, when a second instance of your program is started, you can find the window handle of the first and activate it.
I don't think you have the issue of windows preventing you from doing this in this case, because your second instance is the active application, so it is allowed to 'pass focus' to other windows.
Use Single Application in Qt Solutions
For some applications it is useful or
even critical that they are started
only once by any user. Future attempts
to start the application should
activate any already running instance,
and possibly perform requested
actions, e.g. loading a file, in that
instance.
you can set the setWindowOpacity from 0 to 1 .the only thing is you may open it all the time