There's a couple theming related registry keys that I'm editing through a personal tool:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppsUseLightTheme (to change light/dark mode preference)
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Accent\AccentPalette (to change taskbar color)
I'd really like to update the theme appearance on the fly, but the problem is these changes don't take effect until after restart. The "Theme Settings" in the native System Settings edits the same registry keys, but also manages to update the color of the taskbar etc on the fly.
To understand how the native System Settings is reloading the theme, I've tried monitoring the outgoing window messages in Spy++ and inspecting the API calls in WinDbg. It broadcasts WM_DWMCOLORIZATIONCOLORCHANGED and WM_SETTINGCHANGE (with "ImmersiveColorSet"). But attempting to do the same doesn't seem to have any effect whatsoever:
fn reload_theme() -> Result<()> {
unsafe {
// Send message to all top-level windows.
let broadcast_handle = HWND(0xffff);
SendNotifyMessageW(
broadcast_handle,
WM_DWMCOLORIZATIONCOLORCHANGED,
WPARAM(3812725153), // Arbitrary value
LPARAM(1), // Arbitrary value
);
SendNotifyMessageW(
broadcast_handle,
WM_SETTINGCHANGE,
WPARAM(0),
LPARAM(w!("ImmersiveColorSet").as_ptr() as isize), // Equivalent to L"ImmersiveColorSet" in c++
);
Ok(())
}
}
One other discovery so far is that always updating the key HKCU\SOFTWARE\Microsoft\Windows\DWM\AccentColor causes a reload. There are still elements here and there that don't update though.
How can you "reload" the Windows theme without restarting after theme-related registry changes?
Related
I update my VS code on my MAC to v.1.69.2
when I open it I can't see the icons on the activity bar the icons are still hidden then when mouse over I can see also when I select my file code I can't see without put the mouse over it
any advice to return back my IDE work correctly
This is related to hardware acceleration. Try to disable it in the file /Users/<your_username>/.vscode/argv.json and uncomment the line "disable-hardware-acceleration": true,. Then, make sure you restart the IDE by quitting it first.
It would become the following:
// This configuration file allows you to pass permanent command line arguments to VS Code.
// Only a subset of arguments is currently supported to reduce the likelihood of breaking
// the installation.
//
// PLEASE DO NOT CHANGE WITHOUT UNDERSTANDING THE IMPACT
//
// NOTE: Changing this file requires a restart of VS Code.
{
// Use software rendering instead of hardware accelerated rendering.
// This can help in cases where you see rendering issues in VS Code.
"disable-hardware-acceleration": true,
// Enabled by default by VS Code to resolve color issues in the renderer
// See https://github.com/microsoft/vscode/issues/51791 for details
"disable-color-correct-rendering": true,
// Allows to disable crash reporting.
// Should restart the app if the value is changed.
"enable-crash-reporter": true,
// Unique id used for correlating crash reports sent from this instance.
// Do not edit this value.
"crash-reporter-id": "81f0b16e-4c41-4fd3-b37c-b04c643b5f79"
}
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
}
}
Using Visual Studio 2010 and working with an MFC SDI Application.
I have a CMFCToolbar object owned by the Main Frame.
When the document in this application is created, the MainFrame calls a function to replace one of the buttons in the CMFCToolbar object with a CMFCToolbarMenuButton. The contents of the menu button are populated with information from the document. The menu creation always works. The call to ReplaceButton always succeeds. But there's a visual symptom of the call that I haven't yet figured out.
Any time ReplaceButton is called, the button disappears. Not only is it not drawn, it's not clickable. It's temporarily gone. I assume this is because there's a dangling reference to the old button, which I have just destroyed with the call to ReplaceButton.
I've tried calling Invalidate(), RecalcLayout() to trigger a re-draw, but neither has worked yet. The only reliable method I have for getting the button to show up is re-sizing the application window manually or by un-docking/re-docking the toolbar. I assume there's some kind of lower-level refresh that occurs in these situations, but I don't know how to trigger it manually.
Is there a way to make sure my button is drawn immediately?
Edit: code sample
Count = m_Doc->...->GetCount();
for (Index = 0; Index < Count; ++Index)
{
Caption.Format(L"%s", m_Doc->...->GetName());
m_pLayerMenu->AppendMenu(MF_ENABLED | MF_STRING, LAYER_DROP_SEED+Index, Caption.GetData());
}
m_wndBrushBar.ReplaceButton(ID_BRUSH_TERRAIN,
CMFCToolBarMenuButton(ID_BRUSH_TERRAIN, *m_pLayerMenu, GetCmdMgr()->GetCmdImage(ID_BRUSH_TERRAIN)));
Update:
Calling m_wndBrushBar.AdjustLayout() seems to stabilize the visual behavior of these CMFCToolbar buttons. So that's a partial solution.
Partial because of the following:
It's hard to tell what the real visual behavior is. It turns out that all visual settings/states are stored in the Registry with these MFC objects, and it can hold onto states of dynamically created objects that really alter the startup behavior of the app.
I've gone in to delete the registry values under
Current User -> "Local App-Wizard Generated Applications" -> [My App Name].
Done this a number of times, just to find out what the real behavior of my app is. Feel like I'm missing some fundamental knowledge with the current version of MFC. Lots of bugs arising from the registry deal.
Is there a way to prevent registry settings for certain objects, or to shut off this behavior altogether? Otherwise, I guess my shutdown process will have to be a LOT more thorough with resetting all the visual elements. Registry values seem to ignore, override, or bypass my startup code. I can code how I want an object to look at startup, but if there are values in the registry, it does no good.
You've discovered a sometimes annoying aspect for the CMFC code. That is, the concept of a Workspace. The Workspace manages the concept of the application state. I, too, have had problems like the one you describe. But, you have the flexibility to manage how those objects are recreated by overriding the LoadState () and SaveState () methods.
When my add-on installs it needs to prompt the user to get a username or something like that. After that it stores it and shouldn't ask again. Where would I place this prompt? install.rdf? browser.xul?
There is no explicit mechanism to run code when the extension installs - you should simply do it when your extension runs for the first time. The easiest approach would be checking whether the user name is already set up. If it is not - show the prompt.
It is not recommended to show a modal dialog, those are extremely annoying to users, especially when they suddenly appear during Firefox start-up. You should instead open your page in a tab. A slight complication: Firefox might be restoring a previous session when it starts up. If you open your page too early the session restore mechanism might replace it. So you should wait for the sessionstore-windows-restored notification, something like this should work:
Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");
Components.utils.import("resource://gre/modules/Services.jsm");
var observer = {
observe: function(subject, topic, data)
{
Services.obs.removeObserver("sessionstore-windows-restored", this);
var browser = window.getBrowser();
browser.loadOneTab("chrome://...", {inBackground: false});
},
QueryInterface: XPCOMUtils.generateQI([
Components.interfaces.nsIObserver,
Components.interfaces.nsISupportsWeakReference
])
};
Services.obs.addObserver("sessionstore-windows-restored", observer, true);
A final complication is that your code is probably running from a browser window overlay - meaning that there will be multiple instances of your code if the session restored contains more than one window. You probably want the code above to run only once however rather than opening your first-run page in every browser window. So you will have to coordinate somehow, maybe via preferences. A slightly more complicated but better solution would be having a JavaScript code module in your extension - code modules are only loaded once so you wouldn't have a coordination issue there.
Try using an addonlistener https://developer.mozilla.org/en/Addons/Add-on_Manager/AddonListener#onInstalling%28%29
Or by using the preferences: https://stackoverflow.com/a/958944/1360985
I used the VS 2010 SDK to create and show a custom ToolWindowPane with a WPF control as content. I create a new instance and show it each time a Tool menu item is clicked (the ProvideToolWindow attribute has MultiInstances = true).
When the user attaches the debugger (e.g., hits F5 while in C# project) my ToolWindowPane suddenly hides. I'd like to make sure my tool window is always visible while open, no matter what context the user is in. Is there a way I can enforce that?
I've tried using the ProvideToolWindowVisibility attribute but that automatically shows a new instance of my tool window rather than keeping a remaining one open.
For VS 2010 SDK Microsoft added a new flag __VSCREATETOOLWIN2.CTW_fDocumentLikeTool
You can use this way:
public override void OnToolWindowCreated()
{
IVsWindowFrame windowFrame = Frame as IVsWindowFrame;
object varFlags;
windowFrame.GetProperty((int)__VSFPROPID.VSFPROPID_CreateToolWinFlags, out varFlags);
int flags = (int)varFlags | (int)__VSCREATETOOLWIN2.CTW_fDocumentLikeTool;
windowFrame.SetProperty((int)__VSFPROPID.VSFPROPID_CreateToolWinFlags, flags);
}
This way Tool Window persist open at "Document Well" when you go Debugging
However I have to say this give us some problems when debugging projects, avoiding us to open code files while debugging, like if Visual Studio document management was 'block', there are not so much information for this new flag...
So we preferred to hook to EnvDTE.DebuggerEvents and show the ToolWindow if hide when a debugging session start...
(our ToolWindow has MultiInstances = false)
Implement QueryShowTool
public:
int QueryShowTool(Guid % rguidPersistenceSlot, System::UInt32 dwId, [Runtime::InteropServices::Out] int % pfShowTool);
Enables the VSPackage to control whether to show or hide the tool
window. The shell calls this method when the user switches views or
contexts, for example Design, Debugging, Full Screen.
See https://learn.microsoft.com/en-us/visualstudio/extensibility/opening-a-dynamic-tool-window?view=vs-2017