Is there any way to change the background color of the Solution Explorer in Visual Studio using a Theme? - or any other way for that matter?
I can change it by changing windows-wide color settings, but obviously that affects too much.
Just created VS extension for that in under an hour, search extension manager for "SExColor". Enjoy ;)
#aloneguid ...should have seen this long time ago.. thank you sir !
#ver (regarding vs 2008 solution for solution;) - a B52 type of approach, carpet bombing on anything that is SysTreeView32 inside a devenv.exe. Possible extra param for desired color, otherwise RGB(220,220,220) - works best for me
#include <windows.h>
#include "psapi.h"
#include "shlwapi.h"
#include "commctrl.h"
COLORREF clr = RGB(220,220,220);
BOOL CALLBACK wenum( HWND hwnd, LPARAM lParam)
{
const UINT cb = 261;
static wchar_t name[] = L"SysTreeView32",
tmp[cb] = {0};
if( ::GetClassNameW( hwnd, tmp, 260 ) && 0 == _wcsicmp( name, tmp ) )
{
::SendMessageW( hwnd, TVM_SETBKCOLOR, 0, (LPARAM)clr );
}
return TRUE;
}
BOOL CALLBACK EnumTops(HWND hwnd, LPARAM lParam)
{
DWORD dwThreadId = 0,
dwProcessId = 0;
HINSTANCE hInstance;
static wchar_t derVS[] = L"devenv.exe";
wchar_t name[_MAX_PATH] = {0},
*exe = 0;
HANDLE hProcess;
if (!hwnd) return TRUE; // Not a window
if (!::IsWindowVisible(hwnd)) return TRUE; // Not visible
if (!SendMessage(hwnd, WM_GETTEXT, sizeof(name), (LPARAM)name))
return TRUE; // No window title
dwThreadId = GetWindowThreadProcessId(hwnd, &dwProcessId);
hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwProcessId);
if( !GetModuleFileNameEx(hProcess, 0, name, sizeof(name))) goto exit;
exe = ::PathFindFileNameW( name );
if( (void*)exe == (void*)name ) goto exit; // mhm? maybe not exit?
if( _wcsicmp( derVS, exe ) ) goto exit;
EnumChildWindows( hwnd, wenum, (LPARAM)hProcess );
exit:
CloseHandle(hProcess);
int res = GetLastError();
return res;
}
int wmain(int argc, wchar_t * argv[])
{
if( argc >= 2 )
{
wchar_t *end = 0;
long l = wcstol( argv[1], &end, 16 );
clr = (DWORD)l;
}
::EnumWindows(EnumTops, NULL);
return 0;
}
Even changing the standard Windows background color does not work for the Solution Explorer. This Visual Studio bug report mentions the issue. Microsoft has marked this as "Closed -- Won't Fix."
Which is very irritating! Using a dark theme and having a bright white Solution Explorer hanging on the side of the screen is extremely annoying.
One possible solution is to not use the Solution Explorer at all. The Productivity Power Tools provides a Solution Explorer replacement called the "Solution Navigator." It currently is also hard-coded to white. But I think there is probably a better chance of getting the developers of that tool to add support for modifying colors than of getting Microsoft to do it in Visual Studio. (even though Microsoft created the PPTs.)
Not by any means of configuration from Visual Studio itself.
You can however probably "hack" the window object from the Win32 API (look up "window enumeration"). Once you have the window handle, you can set all characterstics you want.
Regards
/Robert
You could use other extenssion, you have quite big possibilities to do your Visual Studio more good looking ;) (but I'm not sure if there you could change Solution Explorer background)
http://visualstudiogallery.msdn.microsoft.com/20cd93a2-c435-4d00-a797-499f16402378
Related
I try to hook some functions using Microsoft Detours. The method I'm using is CreateRemoteThread + LoadLibrary.
Yet, I've encountered that the exact same code works on notepad.exe, some chrome processes etc., but not on wmplayer.exe(Windows Media Player), Calculator.exe somehow. Is it correct to say that these applications probably tried to prevent this type of DLL injection? I can hardly come up with other possibilities.
Most of these code are copied from the Detours tutorial
The code can be seen and cloned from this repository in case anyone want to experiment them.
DLL:
INT APIENTRY DllMain(HMODULE hDLL, DWORD Reason, LPVOID Reserved)
{
try {
std::ofstream file("D:\\output.txt");
file << "Hello!\n";
file.close();
}
catch (...) {
std::ofstream file("D:\\error.txt");
file << "Hello!\n";
file.close();
}
}
Injector:
int main(void)
{
if (fileExists("D:\\output.txt"))
{
printf("Removing...\n");
remove("D:\\output.txt");
}
PROCESSENTRY32 pe32;
pe32.dwSize = sizeof(PROCESSENTRY32);
HANDLE hTool32 = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);
if (Process32First(hTool32, &pe32))
{
while ((Process32Next(hTool32, &pe32)) == TRUE) {
char exeName[] = "Calculator.exe";
//char exeName[] = "notepad.exe";
if (strcmp(pe32.szExeFile, exeName) == 0)
{
printf("Found %s at %d\n", exeName, pe32.th32ProcessID);
char* DirPath = new char[MAX_PATH];
char* FullPath = new char[MAX_PATH];
GetCurrentDirectory(MAX_PATH, DirPath);
sprintf_s(FullPath, MAX_PATH, "%s\\..\\x64\\Debug\\TestDLL.dll", DirPath);
printf("%s File exists: %d\n", FullPath, fileExists(FullPath));
HANDLE hProcess = OpenProcess(
PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, pe32.th32ProcessID);
LPVOID LoadLibraryAddr = (LPVOID)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");
LPVOID LLParam = (LPVOID)VirtualAllocEx(hProcess, NULL, strlen(FullPath),
MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
BOOL status = WriteProcessMemory(hProcess, LLParam, FullPath, strlen(FullPath), NULL);
auto handle = CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)LoadLibraryAddr,
LLParam, NULL, NULL);
CloseHandle(hProcess);
delete[] DirPath;
delete[] FullPath;
std::cin.get();
}
}
}
CloseHandle(hTool32);
return 0;
}
when the variable exeName is set to "notepad.exe", the file "D:\output.txt" will be created, while setting the variable to "Calculator.exe" won't.
If my guess is correct, is using other injection method(ex. SetWindowsHookEx) the only way I can make these work?
On Windows 10, "Calculator" is Windows App and according to Detours documentation detours doesn't work for Windows App for following reason
Why can't my Windows Store app for Windows 8 include Detours?
Windows Store apps may use only a subset of the Win32 API. Detours
requires several Win32 APIs that are forbidden in for Windows App
Certification. Forbidden APIs used by Detours include VirtualAlloc,
VirtualProtect, and FlushInstructionCache.
As per Microsoft documentation
Windows apps:: All apps installed in C:\Program Files\WindowsApps.
Path of "Calculator" on Windows 10 is
C:\Program
Files\WindowsApps\microsoft.windowscalculator_10.2103.8.0_x64__8wekyb3d8bbwe\Calculator.exe
Personally I think these applications indeed prevented from being injected by the CreateRemoteThread + LoadLibrary method since it's the most basic approach, but this guess needs further proof. After I switched to use the SetWindowsHookEX method in this repository, the DllMain will be called successfully.
I'm trying DwmGetWindowAttribute to get a window's real, physical, pixel location on screen. It works well for top-level windows. But I find that it does not work for child windows, in which case it returns just E_HANDLE (0x80070006).
However, MSDN does not state anything about such child-window limitation. So I'm in baffle.
Can any one confirm this behavior? Thank you.
This is my C++ test code (DwmBounds.cpp):
#include <stdio.h>
#include <windows.h>
#include <dwmapi.h>
int main()
{
DWORD winerr = 0;
HWND hwndTop = FindWindow(L"Notepad", NULL);
if(!hwndTop)
{
wprintf(L"Cannot find a Notepad window.\n");
return 4;
}
RECT rc = {};
HRESULT hr = DwmGetWindowAttribute(hwndTop, DWMWA_EXTENDED_FRAME_BOUNDS, &rc, sizeof(rc));
if (hr != S_OK)
{
wprintf(L"Fail to call DwmGetWindowAttribute() on Notepad window. HRESULT=0x%08X\r\n",
(DWORD)hr);
return 4;
}
wprintf(L"Notepad DWMWA_EXTENDED_FRAME_BOUNDS: LT(%d, %d) RB(%d, %d)\r\n",
rc.left, rc.top, rc.right, rc.bottom);
HWND hwndEdit = FindWindowEx(hwndTop, nullptr, L"Edit", nullptr);
if (!hwndEdit)
return 4;
hr = DwmGetWindowAttribute(hwndEdit, DWMWA_EXTENDED_FRAME_BOUNDS, &rc, sizeof(rc));
if(hr != S_OK)
{
// Always get HRESULT=0x80070006 (E_HANDLE), why?
wprintf(L"Get DWMWA_EXTENDED_FRAME_BOUNDS fails on child window(0x%08X), HRESULT=0x%08X\n",
(DWORD)hwndEdit, (DWORD)hr);
return 4;
}
wprintf(L"Editbox DWMWA_EXTENDED_FRAME_BOUNDS: LT(%d, %d) RB(%d, %d)\r\n",
rc.left, rc.top, rc.right, rc.bottom);
return 0;
}
This is its output:
The benefit of DwmGetWindowAttribute is: Whatever the setting of DPI_AWARENESS_CONTEXT on the calling thread, DwmGetWindowAttribute always reports physical screen coordinate. On the other hand, GetWindowRect just reports the "virtual" coordinates relating to calling thread's DPI-awareness-context. So, I am wondering whether I can use DwmGetWindowAttribute to get each top-level window and child window's physical coordinates.
I have a CMake project with an executable and a static library (linked to the exe). The library is responsible for implementing the creation of the window (using WinAPI for Windows OS), and the executable contains the main entry point (in this case a simple int main(...) function).
I've been googling for a day but cannot find a way to create a window with Aero support (can maximize by dropping to the top, the title bar is a little bit transparent, etc). I've read the Enabling Visual Styles MSDN article but I'm not sure how I should handle this with CMake. Especially that the window implementation is hidden to the client (since it's implemented in the library).
The windowing code is really basic right now for simplicity. Some of the code will be refactored, the point is not that right now. Here is the (almost) full code for creating the window.
bool WindowsWindow::create(const WindowCreateInfo& info)
{
// register custom window class
{
WNDCLASSEX wnd = { 0 };
wnd.cbSize = sizeof(wnd);
wnd.lpszClassName = CLASS_NAME;
wnd.hInstance = GetModuleHandle(nullptr);
wnd.lpfnWndProc = wndProc;
wnd.style = CS_OWNDC;
wnd.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_WINDOW);
wnd.hCursor = LoadCursor(NULL, IDC_ARROW);
if (RegisterClassEx(&wnd) == 0) {
return false;
}
hInstance = wnd.hInstance;
}
HMONITOR monitor = MonitorFromWindow(nullptr, MONITOR_DEFAULTTOPRIMARY);
MONITORINFO monitorInfo;
monitorInfo.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(monitor, &monitorInfo);
LONG style = 0;
LONG exStyle = WS_EX_APPWINDOW;
int x = CW_USEDEFAULT;
int y = CW_USEDEFAULT;
int width = info.width;
int height = info.height;
if (info.isWindowed) {
style = WS_OVERLAPPED | WS_BORDER | WS_CAPTION;
if (info.hasSysMenu) {
style |= WS_SYSMENU;
}
if (info.allowMinimize) {
style |= WS_MINIMIZEBOX;
}
if (info.allowMaximize) {
style |= WS_MAXIMIZEBOX;
}
// ... positioning, adjusting size, etc.
} else {
style = WS_POPUP;
x = monitorInfo.rcMonitor.left;
y = monitorInfo.rcMonitor.top;
width = monitorInfo.rcMonitor.right - x;
height = monitorInfo.rcMonitor.bottom - y;
}
handle = CreateWindowEx(
exStyle,
CLASS_NAME,
info.title,
style,
x,
y,
width,
height,
HWND_DESKTOP,
nullptr,
hInstance,
nullptr
);
if (!handle) {
return false;
}
running = true;
ShowWindow(handle, SW_SHOW);
return true;
}
The loop is the standard Peek-Translate-Dispatch trio and the WndProc only handles the WM_CLOSE message, otherwise returns with DefWindowProc.
How could I enable the Aero support in this kind of setup?
If the proper manifest file would be the solution, how should I handle it correctly? I mean the client (the executable) should not care that the underlying library is using WinAPI or not
A CMake example would be really helpful
Current solution
I was able to find an example (actually from a Vulkan SDK) that pointed out that I need the WS_THICKFRAME style (a resize border) in order to my window become modern looking (Aero-like).
GetOpenFileName fails with access violation. File must be on DESKTOP and have long name.
Problem occurs only after first successful open of the file. Problem occurs when mouse cursor hovers over file as tool tip about to be displayed.
See the answer below. I'm leaving the original problem description below.
Mike D.
=======================
I'm using GetOpenFileName. I sometimes get a access violation deep inside shell32. The violation never occurs the first time this code is used, it often takes five or six tries. Also it appears that if one selects a file in second or two after the open file window pops up, the violation does not occur. Also, the call stack displayed when I debug this does not include any of my code. It's as if some independent thread is waking up to do something.
Any insights into how I might debug this greatly appreciated!
I made a "hello" world app exhibiting the same behavior. It, however, requires many more tries before it fails. It also seems that one has to switch directories before it will fail.
The GOFN is done from a thread created just for that purpose. Below is the code from the "hello world" app.
typedef struct
{
public:
HWND hWnd;
HINSTANCE hInst;
} def_params, *p_params;
DWORD WINAPI ReadLogFile_DataRecorderThread (PVOID pvoid);
void ReadLogFile_DataRecorder (HWND hWnd, HINSTANCE hInst) // ***************************
{
static def_params Params;
Params.hWnd = hWnd;
Params.hInst = hInst;
HANDLE T = CreateThread (NULL,0,ReadLogFile_DataRecorderThread,&Params,0,NULL);
CloseHandle (T);
return;
}
DWORD WINAPI ReadLogFile_DataRecorderThread (PVOID pvoid)
{
p_params P = (p_params) pvoid;
HWND hWnd = P->hWnd;
HINSTANCE hInst = P->hInst;
char ReadLogFileLastDir[256];
// static def_OpenFileHook Hook;
OPENFILENAME ofn;
char fn[MAX_PATH]="\0";
char filter[32]="Text Files\0*.TXT;\0\0";
char title[]="Open IMC Data Recorder Log File";
char defext[]="TXT";
int status;
// Get File Name
fn[0] = '\0';
ReadLogFileLastDir[0] = '\0';
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = hWnd;
ofn.hInstance = hInst;
ofn.hInstance = (HINSTANCE) GetWindowLong (hWnd, GWL_HINSTANCE);
ofn.lpstrFilter = filter;
ofn.nFilterIndex = 0;
ofn.lpstrCustomFilter = NULL ;
ofn.nMaxCustFilter = 0 ;
ofn.lpstrFile = fn;
ofn.nMaxFile = sizeof(fn);
ofn.lpstrFileTitle = NULL;
if (ReadLogFileLastDir[0] == '\0')
{
SHGetSpecialFolderPath (NULL,ReadLogFileLastDir,0x0005,false);
};
ofn.lpstrInitialDir = ReadLogFileLastDir;
ofn.lpstrTitle = title;
ofn.Flags = OFN_FILEMUSTEXIST |
OFN_PATHMUSTEXIST |
OFN_EXPLORER |
// OFN_ENABLETEMPLATE |
OFN_ENABLESIZING |
// OFN_ENABLEHOOK |
OFN_READONLY;
ofn.lpstrDefExt = NULL;
ofn.lpfnHook = NULL; // Hook.DialogHook; // hook routine
ofn.lCustData = NULL; // (long) &Hook; // data for hook routine
ofn.lpTemplateName = NULL; // MAKEINTRESOURCE(IDD_HOOKFILEOPEN);
ofn.nFileOffset = 0 ;
ofn.nFileExtension = 0 ;
ofn.lpstrDefExt = defext;
status = GetOpenFileName (&ofn);
int S;
S = CommDlgExtendedError();
return 0;
}
When it fails, the call stack looks like this...
SHELL32! 7ca4e035()
SHELL32! 7cb2dc16()
SHELL32! 7cb2dd5a()
SHELL32! 7cb27361()
SHELL32! 7c9f40a3()
BROWSEUI! 75f81b9a()
SHLWAPI! 77f69548()
NTDLL! 7c927545()
NTDLL! 7c927583()
NTDLL! 7c927645()
NTDLL! 7c92761c()
KERNEL32! 7c80b50b()
Sorry but I am unable to get symbols for these as I have an old Visual C++ :-(
It appears to me that the problem occurs when the GOFN stuff is about to open the popup describing the file as the mouse cursor hovers over the file name.
The set of circumstances causing the problem are somewhat weird. Experiments show one has to do the following in the GOFN window:
Open a file on the DESKTOP
Hover over a long file name
If I do this twice, it always fails. The file name I used was
IMCLOG_20120323_1658_-_20120324_0653_CST_+DST_E2_2_second.TXT
I tried the same thing with NOTEPAD and the same problem occurs!
I found numerous reports of the same problem. For example:
Social.MSDN Problem report
CodeProject question
CodeGuru thread
There was also a Google cached link to a since-deleted MS Connect bug report. As you discovered, the problem seems to be particular to files in the Desktop.
The only suggested solution I found is to call CoInitializeEx(NULL) at the start of the thread, and call CoUninitialize() at the end, so that's worth trying.
Also, the MSDN documentation for GetOpenFileName() says:
Starting with Windows Vista, the Open and Save As common dialog boxes have been superseded by the Common Item Dialog.
So it may be worth discarding GetOpenFileName() completely.
Can we change/increase the size of console output to view large size of data in console application at once?
There seem to be different ways to Rome:
This should be the recommended way I would think, cause the name says it all: GetConsoleWindow as is demonstrated here.
A quick hack might be the windows API function SendInput. If you simulate Alt+Enter, you could probably fullscreen the active window.
Here are some propositions using API calls from user32.dll
Check out the SetConsoleScreenBufferInfoEx API. It takes a CONSOLE_SCREEN_BUFFER_INFOEX as input and that has a dwSize member which contains the size of the console screen buffer, in character columns and rows.
MSDN for SetConsoleScreenBufferInfoEx Function: http://msdn.microsoft.com/en-us/library/ms686039(v=VS.85).aspx
I once used a small hack that is first setting the console's output buffer and then trying to find the console window and resize it. It worked well on XP, I never tested it on newer Windows versions.
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
SMALL_RECT sr;
sr.Top = 0;
sr.Left = 0;
sr.Bottom = 10;
sr.Right = 79;
SetConsoleWindowInfo(h, TRUE, &sr);
TCHAR title[512];
GetConsoleTitle(title, 512);
HWND hWnd = FindWindow(NULL, title);
if(hWnd != NULL) {
HWND hWndInsertAfter = NULL;
UINT nFlags = SWP_NOSIZE | SWP_NOZORDER;
#if 0 // Don't move?
nFlags |= SWP_NOMOVE;
#endif
SetWindowPos(hWnd, hWndInsertAfter , 40, 350, 0, 0, nFlags);
SetForegroundWindow(hWnd);
}
If you are using the command prompt window, right click it's label on the task bar and click the Properties option.