The documentation for CGWindowListCopyWindowInfo says
Generating the dictionaries for system windows is a relatively expensive operation. As always, you should profile your code and adjust your usage of this function appropriately for your needs.
My question is how can I "adjust" my use of this function? For a code automation process I frequently need to check what window is frontmost among those of document or modal level. That is, I call CGWindowListCopyWindowInfo, ignore the windows that belong to other processes or have levels that I don't care about, and identify the first window that remains.
If there were a way to ask for information about just the windows owned by my process, say, that would be nice, but I see no way to do that. Or if there were a way to be notified when my windows change. I could watch for Carbon Events when windows are hidden or shown, but of course that is a deprecated technology.
You can use [NSWindow windowNumbersWithOptions:0] to get the window numbers of just the current application's windows (on the active space) in z-order.
TL;DR - How does the Spy++ tool really construct its process list?
Stage
We have an MFC desktop application (running on Windows XP) that is hanging in that it doesn't react to any user input anymore. It is redrawn when switching to it via alt-tab however. (It does receive WM_SETFOCUS, WM_ACTIVATE, etc. It apparently does not receive any mouse or keyboard messages.)
Since the app is hanging in some limbo, we pulled a few process dumps, but these were of little help so far. Enter:
Spy++
We used Spy++ to find the information I gave above about the window messages this application seems to be processing. We did this by Opening the Windows View and selecting our application Window and in the Messages properties selected Windows of same process and Messages to View : Select All.
However we first tried to view all messages of this process by opening the Processes View of Spy++ and our application is not shown in this process list. Cross checking on another PC where the app is running normally, the process is also normally shown in the processes list of Spy++.
Can anything about the misbehaving app be inferred from the fact that the process is not shown in Spy++'s Process View, but the main window of the app is shown in the Windows View. Why would a process with a main window that is visible not be shown in Spy++'s Processes View?
The process is listed in Task Manager and in the Attach Process Window of Visual Studio 2005. So these tools apparently use a different method to list processes than Spy++ ... ?
The system where the app is currently hanging is a Windows XP SP2 system and we've used the Spy++ Utility that comes with Visual Studio 2005.
The behavior does recur occasionally, but only after the App has been running for several days!
Running Vista or later? Your process is probably elevated and Spy++ is not. Newer versions of Spy++ require elevation. So, try elevating Spy++ explicitly and see if that helps.
Yes, of course things can be inferred from this. Don't take anything I say too seriously in this context, I'd have to go look at the code. But I believe that Spy goes off and looks at the EnumProcesses API. (http://msdn.microsoft.com/en-us/library/ms682629.aspx)
So, if your process isn't showing up there... hrm.
But, what is different between the system where it's working and the one where it's not?
Spy++ requires the following two values in the registry to be disabled (0) to display the processes/threads list AT ALL:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\System\CurrentControlSet\Services\PerfProc\Performance
Disable Performance Counters -> either 0 or not present
Was going insane trying to find out why it refused to display them. It's some kind of bad joke - this debugger requires itself a debugger to get it working! Not that WinDBG would display any meaningful info, MS doesn't even provide a symbol file on their symbol server, pfft.
Anyway, maybe it doesn't display processes that have their performance counters disabled, because I think, this can be set on individual basis, at least for services, like:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
Disable Performance Counters
So it's basically always a value of the "Performance" subkey. All this stuff is undocumented, it makes use of advapi32.dll functions like "PerfRegQueryValue" and "PerfRegQueryInfoKey"... don't ask me.
I am planning to follow one of the suggestions made here to control window dimensions, hide/show and bring to front of a window owned by a different process from my process.
Window manipulation using window-handle from different process on MS Windows(XP)
How can I control the size and position of a new process Window from a WinForms app?
Will my process be reported as malware by any of the malware detection software you know?
Will my process need any higher privileges to control the other process window than the highest of the privileges with which my process and the other process are running?
I suggest you use UI Automation to manipulate another application's window.
This is probably the best way to ensure your manipulating application will not be seen as malware, as UI Automation is 100% part of the OS, not a HACK, supports security. It also application authors to add or remove automation capabilities to their application. See this somewhat related thread here on SO: https://stackoverflow.com/questions/5383600/win32-vs-ui-automation
I'm thinking of writing an X11 window manager which does for windows something like what TabKit does for tabs in Firefox (in its default tree view mode). To do this, I'd need to be to able to find out which window a window was opened from. Is there a standard way of finding this out?
(I've never done any X11 programming without using a cross-platform toolkit on top of X11, let alone writing a window manager.)
For the difficult cases - applications launching other applications, e.g. a word processor launching a web browser - there's going to be a need for co-operation between applications to track this information. The Zeitgeist project already seeks to track which documents were opened from which documents, which is close enough that I should probably work with Zeitgeist (and/or its KDE equivalent - Nepomuk?) to get this implemented.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Ultramon is a great program for dual monitors (stretching screen across monitors), but I was wondering if there is any way do to something in Visual Studio like have one tab of code open on one monitor and a second tab of code open on the second monitor with only one instance of Visual Studio running?
Or are there any other suggestions on getting most bang for buck on dual monitors and Visual Studio?
have one tab of code open on one monitor and a second tab of code open on the second monitor with only one instance of Visual Studio running
you can simply drag a Tab outside of VS onto your other screen.
Personally, I have my windows set up so that one my main monitor, I have the main visual studio monitor, so therefore my code window, maximized, with only the toolbox docked, on the left. This means the code window takes up as much space as possible, while keeping the left hand edge of the code close to the middle of the screen, where my eyes naturally look. My main monitor is a wide screen, so I find that gives me more than enough room for my code.
My secondary monitor has a second window, which contains the tool windows that I use. So I have solution explorer, error list, task list (//todo: comments), output window, find results etc. all taking up as much space as they like on my secondary monitor.
When debugging, the solution explorer moves the main monitor, and the watch, autos and locals windows take its place.
I find this gives me a very large area to write code, and really helps usage of all of those additional windows, by giving them more real estate than they'd usually have.
Update: In response to everyone talking about using the second monitor for documentation or running the app, I wholeheartedly agree, and forgot to mention how I do that. I use PowerMenu alot to acheive this. Basically I can right-click on any window and set Always On Top. So while i'm debugging, i want to see my output window, but then if I have to refer to some documentation, I just flick to Mozilla (on the second monitor), set it on top, and go back to visual studio. I find this lets me manage the tool windows without having to either shuffle them around a lot, or take up valuable space in the code window.
I have three monitors, so I usually run with this configuration:
Left Monitor: documentation / ebooks.
Middle Monitor: code / debugging
Right Monitor: Test application / scrolling logfiles (if needed)
This usually works pretty well, and since the monitors are fairly big I rarely need to use the test application in full-screen, so there's plenty of room for my tail -f windows.
I also use AutoHotkey to assign hotkeys that flip to the most important windows, like Firefox or my SSH session. That way I can simply use a shortcut key to access them when necessary.
The left monitor is actually a separate computer running Linux and keyboard/mouse shared with Synergy, so I have multiple ebooks or documentation pages open, one on each virtual desktop... I can flip between the documentation by moving my mouse to the left and using a shortcut key.
When I first got two monitors I wanted to do the same as you, use all the space for visual studio, but I think that you come to realize that it's best to keep VS on one monitor and use the second monitor for documentation, external resources etc. You wouldn't think it at first, but all the little touches like just being able to maximize other resources without them hiding your code is a great feature.
For GUI debugging is awesome being able to run the app into one screen and having the debugger in another screen. That's one of the most practical uses..
But really, depends on which kind of application you're developing, i.e., if you need to monitor open file handles, logs, etc.
I have VS in my left monitor and the GUI/running window in the right. However, if you want to have to code tabs open on each monitor, you could use UltraMon's option to expand a window across both monitors, then drag a code page over such that it puts up a divider. Then, you align that divider with the break in your monitors.
I've done that before, just to test it out. It's not a bad setup.
Three monitors -- all 1600x1200
Left: Email, IM, SQL Server Management Studio, Remote Desktops to servers
Middle: VisualStudio -- maybe multiple instances -- maximized, solution explorer and team explorer docked on right, errors/output docked bottom, others auto-hide
Right: Web browsers -- app debugging and normal web work, ADUC (if needed)
Other apps get moved around depending on what I'm working on and how crowded the monitors are and the interaction between the app that's open and what I need the info from it for.
I have three monitors, set up where Visual Studio is full screen on the middle monitor, the right hand monitor has all the tool windows configured and the left monitor is for browser, help, SSMS, email, etc..
Works well except if I have to remote in, so I have a separate exported configuration to bring move the tool windows back into Visual Studio, and one to set them back up for multiple monitors.
Though I use StudioTools for other purposes, it has a "Tear off Editor" option, with which you can "tear off" the file to a window and resize the window. Find it quite helpful
I find the Code Definition window absolutely invaluable to have open in my other monitor. As the cursor moves over a type name in your editor the other window shows its definition.
You could try right-clicking a file in solution explorer, Open With, and then go find devenv.exe. That will open it up in a new instance of VS. Plus, it saves devenv as one of your default options in the future, so you don't have to go hunting around for devenv all the time. Not beautiful, but an option.