As yolu may have noticed, MS introduced a modern kind of 'theming' in Windows 10 regarding the basic OS elements like start menu and taskbar. With newer versions, you can choose a 'light' theme as an alternative to the default black theme.
I was wondering if there is an API or hook to elegantly and (more importantly) efficiently check live for theme changes (Did not find anything in the MS docs regarding this, but often enough these gems are pretty hidden there IMHO).
Specific problem: When you have a desktop application with a system tray icon, chances are high that you designed it to be bright. Nearly all of the modern Windows icons feature such a style (simple and white, yielding good readability on the black taskbar). Now you can provide a different version in a darker style for the light theme, but how to notice when to apply this on the fly?
I'm aware of the registry key under HCU (Software/Microsoft/Windows/CurrentVersion/Themes/Personalize) which is what I'm utilizing right now. However, blindly checking for change every x milliseconds seems pretty awkward.
If no such thing is available, I'm also happy to hear some ideas for more efficient implementations of such a check.
Method 1： Use RegNotifyChangeKeyValue
Notifies the caller about changes to the attributes or contents of a
specified registry key.
Methon 2: Use WM_SETTINGCHANGE
Applications should send WM_SETTINGCHANGE to all top-level windows when they make changes to system parameters. (This message cannot be sent directly to a window.) To send the WM_SETTINGCHANGE message to all top-level windows, use the SendMessageTimeout function with the hwnd parameter set to HWND_BROADCAST.
I tend to use the second method, I have tried, and have been able to work successfully.
Minimum code example：
case WM_SETTINGCHANGE:
{
if (!lstrcmp(LPCTSTR(lParam), L"ImmersiveColorSet"))
{
//theme has been changed
}
}
Related
I ran into a reproducible bug which doesn't really make sense to me. Hopefully someone knows more about the internals of keyboard input under Windows (I'm using Windows 7) and can point me in the right direction on how to solve it. As it stands now I don't really know where I should start to look.
My application creates a global keyboard hook, using the MouseKeyboardActivityMonitor library. This was working fine for me, but I quickly received bug reports from people using different keyboard input languages. When they write letters with accents, e.g. ë and ê, they show up as ¨¨e and ^^e respectively. This bug is also reported on the library's website, but hasn't been resolved yet.
To try to reproduce the bug I set up an alternate input language 'Dutch (Belgium)' next to my existing 'English (United States)'. After some toying around I discovered the following:
The bug doesn't occurs when the application which installs the hook has focus, and language is set to 'English (United States)'. Writing in any other application (e.g. notepad) and using 'Dutch (Belgium)' to write the special characters work. The bug does occur when the application which installs the hook has focus, and language is set to 'Dutch (Belgium)'.
I am looking for any clue as how the two are related. Perhaps I need to introduce some extra checks in the keyboard hook library? The source code of the keyboard hook is available on line.
It seems that the input language is not updated in your application. Looking at the source code of the library that you are using, it seems that they use this call to get the correct keyboard layout:
internal static extern uint GetKeyboardLayout( int dwLayout );
The documentation of this method however emphasises:
The input locale identifier is a broader concept than a keyboard
layout, since it can also encompass a speech-to-text converter, an
Input Method Editor (IME), or any other form of input. Since the
keyboard layout can be dynamically changed, applications that cache
information about the current keyboard layout should process the
WM_INPUTLANGCHANGE message to be informed of changes in the input
language.
However, based on a quick glance at the code, the library does not seem to respond to this WM_INPUTLANGCHANGE message, which might cause this behaviour
Also, here is a useful link to an explanation how the Keyboard is handled by Windows
In Windows 7's Windows Explorer list view (what allegedly is not list view at all) in the Details view, you can start selection marquee in the first (Name) column. You just need to start outside the actual name.
The same is true for default-style list view control in Details view.
But if you set the list view control to the Explorer style (using the SetWindowTheme), what should mimic the Windows Explorer, this does not work anymore. You can start selection in the second and later columns only.
SetWindowTheme(listView1.Handle, "explorer", null);
Is there any way to make list view mimic the Explorer selection style?
I suppose there's no settings to enable such behavior and this would have to be coded. Like handling the mouse down and triggering selection. But I have no idea how to do that.
Thanks.
Ntb, I'm using C++Builder, but this should be purely Win32 issue. I've tested this with WinForms too (hence the C# sample above).
Is there any way to make list view it mimic the Explorer selection style?
No, SysListView32 in explorer theme does not behave that way. The control used by the modern Explorer is actually DirectUIHwnd. And you are not able to use one of them.
The only way to get the behaviour of DirectUIHwnd is to code it yourself. I expect that's possible to do but I'd also expect it to be very difficult to achieve.
Actually there is a way to mimic Explorer selection behavior. It requires a lot of additional declarative work, but it is possible.
You need to get undocumented IListView interface via undocumented LVM_QUERYINTERFACE message (note that interface declaration and GUIDs are different for Windows Vista and Windows 7+). Details about constants and declarations can be found here:
IListView at Geoff Chappell - Software Analyst or
Undocumented List View Features at Code Project.
After acquiring the interface all you need is simply a call to SetSelectionFlags(1, 1) method. Voila you are done.
We have an 'enterprisey' system with a scheduling component which gets floored if any dialogs come up. If any modal dialogs come up in the processes it is running, it gets 'paused' and can't kick off any new processes.
Excuse me a minute ...
*goes outside*
*laughs*
*cries*
*comes back*
.. ahem ... so anyway we need some sort of tool/technique that can lurk in the background and automatically detect specific dialogs and click OK on them. Any recommendations?
The offending system is running in Windows XP.
(NB: changing the third-party-enterprisey system or making its developers sit on the naughty step until they improve it are not options in the short term)
From this similar question I found:
Buzof by Basta Computing
which did the trick.
There is also a product called DialogDevil which looked promising but didn't work in our situation for some reason.
AutoIT is absolutely perfect for this. You can use the tool to help identify the dialog, write your own simple code and distribute the "auto clicker" via exe. It lurks in the background by running from the task tray.
DialogDavil will require exact same parameters on your dialog (for which you want buttons to be autoclicked) every time that same dialog pops up. And thats why it didnt work for me in first pass. Then i changed the control file at the following path to remove the changing items (a text box text in my case)
C:\Users\userName\AppData\Roaming\DAIR\DialogDevil\control.xml
And then it worked like a charm.
HTH,
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.
In other words, can I count on a control ID as a reliable identifier?
From some reading I've done, it sounds like .NET controls can have control IDs that change with every run, is this so for Win32 apps as well, or are they something that's hardcoded in the source?
The window/control in question is actually an Internet Explorer dialog if that helps.
In general win32 dialog resource IDs do not change when you run the app. However, they are internal implementation details and as such they are subject to change whenever an update (patch, service pack, major release) to the application is made.
In general all of IE's dialogs use hard-coded control IDs. There may be some that are dynamic. If you give the specific control I might be able to give you a better answer.
The answer is "it depends on the circumstances, but in the majority of programs, these will not change across multiple executions." In general, a control ID or resource ID will be the same across every execution of the same program.
In most implementations, resources are stored in the resource section of the PE executable and are assigned a resource ID within that data structure. Usually, the developer specifies the resource in a .rc file.
The exceptional case is via APIs such as CreateDialogIndirect() which allow IDs specified through the API at runtime. Such dynamic creation is uncommon, however. Consistency of resource IDs and control IDs is the expected condition, so even in the case of the CreateXXXIndirect() API, users of the API would be ill-advised to chose a varying ID.
Microsoft has spent years trying to deal with applications which embed assumptions about internal windows implementation details. One of the biggest causes of compatibility problems for IE8 was caused by applications which made assumptions about the window order of IE controls. When the UI was changed in IE8, the controls moved and a number of browser plugins broke hideously.
In general you should never ever make assumptions about controls in an application that you didn't write - your code WILL break in the future (not might break, will break).
As a general rule, no they don't change between runs. Control IDs are usually specified with a dialog template, and that's a static resource compiled into an .exe or .dll. Controls can also be created using a regular call to CreateWindow or CreateWindowEx. In such cases, the ID is usually a constant, but it could be anything in principal (even a random value).
In any case, if you're planning to muck around with a dialog in another application, then you are asking for trouble. Control IDs can and do change between different versions of a program.
It depends on the control. Controls that are dynamically created could have a different ID every time they are created. Controls based on static dialog resources will have static IDs.
Even if a dialog is backed by a dialog resource template, controls can be added dynamically at runtime and those controls could have dynamically generated IDs.
Depending on your intent, it may be acceptable to store and reuse it for future lookups or traces; but in general it isn't safe.
If the window is based upon a dialog template, items declared in the template generally don't change. It is perfectly safe under typical circumstances to use these as identifiers.
Sometimes the window class name or a portion of it can be used as an identifier instead, depending on the window host.
If the dialog is one of the standard prompts from internet explorer, you may want to use text stored in adjacent controls or the dialog caption as additional verification info (if localized versions of IE are not an issue). If the dialog is a window that embeds an instance of MSHTML/IE; none of these options may be viable- but you can use OLE accessibility to get at the document shown and then browse the DOM from there.