I'm looking a way to inject PowerShell window to Windows Taskbar since I often use it to do many tasks by my local PS-modules
Maybe it can be done by some external toolbars? I didn't find any information about it.
The result I look for:
Related
In Windows 10:
Is there a way to use Powershell to modify the taskbar functionality? I know 7++Taskbar Tweaker does this, but I was curious if this can be done via Powershell as I can't use Taskbar Tweaker.
Goal:
Have multiple icons of same program open, next to each other, with no labels.
For example if I have a copy of PROD open in SSMS, and DEV in another instance of SSMS, I would like to click once just on the PROD (or DEV) without waiting for the hover to come down. I know this is not a major deal, just curious if powershell can do it and how.
Thanks for your help.
You mentioned 7+ Taskbar Tweaker. There's a library of the same author, 7+ Taskbar Tweaking Library, which you can use. Regarding PowerShell, this might help: Run my third-party DLL file with PowerShell.
I am trying to write a program what will manage few console windows, my program will be able to CreateProcess() for new console windows, get a window main handle and the use that handle to resize, close, hide, change title etc. But I cannot find a reliable way to get a main window handle. The purpose is to have a tab bar and switch between created console windows with the click on the tab.
I have tried few ways:
1) use windows "cmd.exe" ability to set window title, and then FindWindow("tmp_title"...)
This has a problem, I do not need cmd.exe running, and also I need a processID for the target program not the cmd.exe. Maybe I should use this way but check for children subprocesses?
2) EnumWindows() then CreateProcess() then wait 40 ms, then EnumWindows() again and find the new window.
This is unreliable! I got two new windows sometimes for weird reasons.
3) use GetWindowThreadProcessId() + EnumWindows(). This worked the best on XP, but on win7 the found window seems to be the wrong one, it's GetWindowText() returns "DefaultIME" and hide/show of this window does nothing. So it is obviously a wrong one.
So any idea how to do it reliably and if possible cross-platform (Cross-windows, XP,Vista,7)
I want to enable users to view the windows Quick Launch bar via DLL call (I checked the registry modification option but it's the route around).
I know the functionality is stored in shell32.dll and it the DLL can be accessed by rundll32.exe.
rundll32.exe shell32.dll
My question is:
Can anyone point me to a through reference of the shell32.dll entry points and arguments, or knows of a program that extracts it from the DLL itself?
Raymond Chen from the Windows shell team discusses this in a blog article.
In short there is no documented, supported way to do this on XP. You'll need to continue using the hack you've found. In Vista you can use ITrayDeskBand. Windows 7 task bar is, of course, different again.
Raymond also points out that programs should not be changing the user's choice of visibility for the Quick Launch bar.
That's not something a program should be doing. Whether
the Quick Launch bar is shown or hidden is an end user
setting, and programs should not be overriding the user's
preferences. Explorer consciously does not expose an
interface for showing and hiding taskbar bands because it
would just be a target for abuse. Much like the program that wants to uninstall other programs, the taskbar would become a battleground among programs that each wanted
to force themselves on and force their opponents off. The user is the arbiter of what goes into the Taskbar.
I'm developing an application for debugging purposes. I want the user to be able to select the process to be debugged using the mouse. Process Explorer does a great job of this with the "Find Window's Process" feature. What I can't figure out is how it does this? Does anyone know the Window's API that provides this functionality?
Thanks, Grant
I haven't tried this, but it should work: Use WindowFromPoint to get the window handle, then use GetWindowThreadProcessId to get the ID of the process that created the window.
Alternatively, you could use EnumWindows to enumerate all top-level windows on the screen, filter them by some criteria (e.g. position) and then use GetWindowThreadProcessId to get the process IDs.
If I understand you correctly you are looking to enumerate all Windows and perform some action when the target Window in question is found. You can do this by enumerating all current windows and then performing some action when the user is over the window in question. You will have to associate that window handle with a process.
This is not a simple task as it requires going through a lot of hoops but it is possible, just have to put all the pieces together.
In Visual Studio's Attach to Process dialog, one of the columns in the Available Processes list is "Title", which lists the title of the topmost window owned by each process.
We spawn multiple instances of several server processes in order to compartmentalize the work. For these console processes, the Title field is blank, so currently we have to look up the process id in our management tool in order to find the correct process.
In order to streamline the debugging process, I would love to be able to use the Title field to directly determine which process I want.
SetConsoleTitle does not do the trick, nor SetWindowText with a NULL hWnd. To the best of my knowledge, a console application does not intrinsically own any window handles that we could pass to SetWindowText. We don't want to create any visible windows for these server processes.
Any suggestions for a reasonable way to trick Visual Studio into displaying some useful information here?
I think you might be out of luck. The console window does not belong to the console process, but instead belongs to a system process (conhost.exe on win7 and maybe vista, csrss.exe before that) so if Visual Studio is just looking for a processes top level windows it won't find the console window. Probing consoles out of proc is not supported as far as I know, so there is probably no sensible way for visual studio to see the title of the console windows you have.
One possible solution might be to create a top level window in your console process as a debugging aid. You might want to conditionally compile it, so it is only available when you're debugging though. Just create an additional thread which pumps messages, and create a top level window. If you set the right styles the window will be invisible. You might not want to ship with the window in the code because in long running server code, windows always increase your attack surface, even if only a little bit.
This is probably not very helpful, but it is worth mentioning that on windows the preferred way of portioning up work would be to use threads rather than multiple processes. A process is an expensive object, and threads are much cheaper in terms of system resources as well as being easier to debug.