I am a noob when it comes to Desktop GUIs. Is there a way for me to programmitically figure out which application window is the top most in terms of display environment?
So, basically, I can have a process running in the background, that might then change the behavior of the top-most (or say the selected) window. My go to operating system would be MacOS (then Linux family). Also, for instance, there is an app called spectacle app, which listens to key bindings to snap resize and move active windows on MacOS.
Related
I have a VB6 executable we use as a Starter executable for our real program.
The problem is that windows 7 shows a new icon in the taskbar for the new process, instead of the one i clicked on to start my program (of course, because the starter exe has already ended, and the new exe seems to be a new program).
Currently I use the Shell object to start the other exe. Is there a better way to do it from vb6, maybe by using a native C function with declare that does start an exe in the current process, without spawning a new process?
EDIT:
Thanks to atzz for the great information about Application Model IDs. I now have a shortcut to my app starter with a well defined id, and my app also sets the ID when started, and is now accesssible beautifully from the right icon in the toolbar. However, two problems persist:
The app is a Java App started with Exe4J, and I don't have any chance to set the AppID before Exe4J shows the splash screen, so while showing the splash screen there is a second icon in the taskbar.
If I don't manually drag my starter app icon from the Desktop to the toolbar, but instead use my apps icon and set it to be "sticky", the real app is sticked, and not the launcher.
Both problems would be beautifully solved if my launcher would start the app from within its own process. I heard something of using exec() instead of fork() for linux programs to achive this... is there something similar for windows?
I believe there is a way to accomplish what you need via Windows 7 taskbar API, though I never did it myself and thus don't remember clearly enough what I've read on the subject. Look around the Application ID concept.
Some links:
Developing for the Windows 7 Taskbar – Application ID
Inside Windows 7 - Introducing The Taskbar APIs
If the problem is the icon, why not give both programs the same icon (and the same App.Title). Then the user won't be able to tell the difference between the two taskbar entries. Presumably they aren't both visible at the same time.
Alternatively set your starter app not to appear in the taskbar (Form property ShowInTaskbar = False in the design view)
When I install a virtual desktop manager on Windows 7, and I switch to a different virtual desktop, all the current windows disappear, also disappearing from the Start Menu.
I want to hide some of a particular application's windows, but not all of them, in a similar manner. How can I hide a window like this?
In particular, I need to hide a VirtualBox Seamless mode window, so I'm not sure minimizing the window will work. It does, however, disappear when using virtual desktop managers.
The same window cannot appear on multiple desktops. If you need your application window to appear on multiple desktops you need to create a separate window for each desktop. The desktop a window appears on depends on the thread that creates the window. You can change the desktop thread assignment using the SetThreadDesktop function.
The answer is simply ShowWindow(SW_HIDE) and ShowWindow(SW_SHOW). I think "Virtual Desktop Managers" just hide windows and show them as necessary when the desktops change.
Mac OS X determines what area to scroll by the mouse position. Windows does this by what application is active.
So I thought anyway. If Notepad++ is the active application in Windows, I can scroll underlying applications by placing the mouse pointer on them. But this seems like the only application with this behaviour. Windows Explorer (Win7) doesn't even allow scrolling in the side pane if the pane is not active.
My question is, can this be controlled by developers, and why is Windows behaving like this? I am not about to make a Windows application, but as a developer this makes me curious (and annoyed).
There are a number of applications that do the focus-window-under-mouse, but I like Alt-Drag: http://code.google.com/p/altdrag/
Since the code is Open Source, you may find something reusable there.
I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.
We have a Linux based system that does not use a Window manager. When we start certain applications (for instance Firefox) from a terminal window (e.g. Firefox &) we find that no matter what we do, we can't get the application to display full screen.
If we run xrandr, it shows the default resolution is 1280x1024, but when we try to maximize Firefox (by pressing F11) the application is only sized to 1203x650.
Another application that seems to have the same problem is the evince PDF reader.
Our application is not configured to run a window manager (and we don't want to add one), so I'm wondering if there is something else that we can do to get these applications to render full screen.
Thanks...
Although you don't want to use a window manager, you might need to use a window manager.
I haven't dug into the X server sources around this, so I can't definitively say X requires a window manager to run properly. But as somebody who writes X client code, and hacks the X server, on minimalist embedded devices with small screens, low CPU power and no GPU... let's just say, all the major players in that space use one, and have good reasons for it.
If you want to avoid chewing up a lot of disk space, RAM or CPU power doing window management, you should check out matchbox. It's a low-footprint window manager designed to meet those criteria, and it's what many folks in that minimalist embedded space are using. My employer uses it on cell phones, configured so that only one app at a time is visible to the user, and the foreground app takes up the whole screen with no window borders. But you can use it other ways, too - Nokia uses it for their Maemo-based network tablets.
You could use xwit(1) to forcibly resize and place the windows. But as as far as I know, X11 in itself does not have the concept of a "maximized" window; the very idea is only added by most window managers and/or applications (like Firefox).
Does passing the "-geometry=1280x1024+0+0" option to Firefox help?
Oh, also... if you don't explicitly set a window manager, you might be unexpectedly falling back to the default X11 window manager. If you're not absolutely positive there's no window manager, you should check into this possibility.