I need to take a screenshot of a currently hidden window without giving focus to that window. I saw a post on this, here: Window screenshot using WinAPI
I've never used this method, so any advice is greatly appreciated.
I would like to be able to do this either in Windows or OS X, is it possible to do in OS X? It doesn't necessarily need to be in the same language or be cross platform, but of course, that's a plus :).
I would investigate the possibility of asking the window to draw itself into a bitmap, rather than trying to take its picture with a screenshot. That might be a way of making it irrelevant that the window is minimized. Something like the WM_PRINT or WM_PRINTCLIENT message. I suspect that's actually what the person was trying to do who asked the original question that you linked to. The biggest pitfall is if the window doesn't handle that message appropriately. Not all apps are so well-behaved. Also, I don't think it works for windows that are truly hidden, but I can't tell from your question and the flurry of articles you link to whether or not that's a real concern.
Unfortunately, I also know nothing about programming OS X; I'm just a user on that platform. You might try diving into the Qt sources to see how they're doing it cross-platform, if that's really important to you.
It's hard to imagine that you could have one solution that would work on Windows and OS X. The windowing frameworks are completely different. It would be harder to try to come up with one solution that to write two.
On Windows at least, I'm not convinced you'll have much luck taking a screenshot of a hidden or obscured window. When you search for this on the web, there are a gazillion hits for people asking that very question. None of them appear to have succeeded. If you factor in DWM and Aero glass then I think your chances of success are limited.
Related
All I want is to make a simple application that you can resize while rendering.
(IE resize while never once seeing the buffer out the edge of the screen)
Most commercial, professional, and major open source programs seem to be capable of this, while most all personal or hobbyist programs never seem to be capable of this. (I have no idea why)
I want to make a professional looking program like that.
A few examples of what I'm talking about:
https://gamedev.stackexchange.com/questions/127691/how-to-stop-sdl-from-freezing-the-rendering-while-resizing-the-window
https://www.gamedev.net/forums/topic/488074-win32-message-pump-and-opengl---rendering-pauses-while-draggingresizing/
https://en.sfml-dev.org/forums/index.php?topic=19388.5
What I have used in the past for windowing are:
SDL (Currently)
SFML
GLFW +OpenGL
And this problem applies to all 3 from what I can recall.
I would like to know the following:
If this is a problem that is solvable, please tell me why or why not
I've never once looked that low-level (OS APIs nor Graphics back-ends) so I just want to know why.
What's the way to solve this? Is it within my means?
Is the solution -really- a perfect solution? I've seen many people suggest solutions that have various problems
(IE minimizing the buffer but not getting rid of it entirely OR you got rid of it but there's a ton of flickering (I forgot why but it doesn't matter))
My current understanding is that this a Win32 API/Windows API related bug related to blocking.
I don't have any deeper understanding or knowledge on how to create my own solution easily, but if I must learn then I will.
Should it be possible to develop a dynamic desktop for the Mac? By "dynamic," I mean a desktop whose images take system parameters, such as the time and job information, and use this information to update the image. Information about image states would also be preserved between sessions. I'm not talking about a movie or a stochastic but autonomous screen saver. Is there any reason a user couldn't develop such a thing? (I'd like to ask how but am trying to keep the question constrained.)
I'm not new to programming but have no sense how Macs work. I'd like to know if there's some fatal flaw in my goal before I start digging in. Thanks in advance for any pointers.
Update: Wikipedia implies there's no direct way to do what I want to do--Mac desktop wallpaper must come from a folder of static images or a screen saver. The only viable approach I see at the moment would be to generate images periodically for such a screen saver (e.g., by adapting this Python script). If this is stupid or a slicker method might exist, would love to hear it.
Very late response but I only stumbled across the question and noticed some recent interest...
Aren't you looking for something like GeekTool ?
This seems to have been implemented in the latest version of Mac OS X: Mojave.
This article has some tips on how to make your own, towards the bottom: https://www.howtogeek.com/369645/download-more-dynamic-wallpapers-for-mojave-or-make-your-own/
I am running windows7 on my laptop, and all is well, but I am jealous of the multitouch on macs. I don't really know how all of this "works", but i'm imagining that it couldn't be that hard to write a program to patch into windows that allows this.
Currently, if I put two fingers on the pad and drag around, it sortv half-heartedly tries to follow both. Or something. It's pitiful. After extended experimentation, I don't think it can really track both points at once. But perhaps I could detect the fumbling that occurs when I put my second finger down mathematically, and then "release" tracking on one of them.
Basically, I'm not trying for true multitouch (like stretching images), but I feel like I ought to be able to get something together that detects a double press as a right click. That's a step in the right direction.
What would I need to write that in? How would I install it?
If you're going to say it's impossible, then ignore that and take it from another direction. What if I wanted to enable a triple tap as a right click? (please no pre-built 3rd party solutions, I want to write this myself) That's certainly got to be possible.
How do I tap in to the resources I need?
This might be a hardware and or driver limitation. Not all touch surfaces (like trackpads) support multitouch.
You might want to check out Raw Input on msdn which supports alternative input methods.
Edit:
Note that the Raw Input API only provides access to multitouch if its supported by your hardware.
This is not possible, this is discussed on the www.insanelymac.com forum, where people create hackintosh pcs (basically pcs running mac osx). Several attempts have been made, but DUE to the construction and METHOD with which MANY touchpads collect sensory data it is impossible. Best of luck...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I really want to know if I'm missing anything obvious in the software I'm developing.
What User Interface features that you consider important are often missing in most software?
Undo is bitchy to code, but very useful to the end users.
Save the location and size of all/any windows, so they are restored whenever the program is restarted.
Read this article on Undo from a usability expert (Aza Raskin): Never Use a Warning When you Mean Undo. Coding undo is not all that hard: examples [1], [1.5], [2].
These are some of the UI features that I often find are done badly, or are even missing:
Restoring window state properly.
Conforming to the average (non-beginner, non-expert) user's mental model.
Restricting the number of choices that the user has to make.
Restricting the amount that users have to read while using the app.
Strong consistency with other apps of the same genre running on the same platform.
A well-done Undo / Restore facility.
As somebody else remarked, context-sensitive help.
Allowing an app to be navigated without the aid of a mouse.
Good multi-monitor support.
keyboard Shortcuts
What's usually left out in UI's? Nothing! (literally. empty space). The question is better asked "What can be taken out?". When you have to think of what else your UI needs, you have already gone too far. Leaving out empty space is something UI programmers need to work on. Nobody likes feature creeping.
Remember the KISS rule.
A help menu with more than About...
Context sensitive help
Tool tips
An API and a scripting language so I can bypass the UI.
Seriously. Nothing is more tedious (and error-prone) than having to point-and-click through some repetitive process.
Right click context menu on things like tree views and grids.
We have an record management application here at work that I have to use now and then and they don't have right click on any of the documents in the treeview so you have to keep going to the bottom of the screen to mark a task as completed grrr, and no keyboard shortcuts too grrr
Consistency in your design... There are too many apps that "look" like a programmer wrote them. I can't stress enough!
Automation... Office has it, I wish more apps did.
CLI... As mentioned above, especially if it's a repetitive-wizard-type process
Templates/Presets... like Handbrake... make life easier, not to mention handy in the training process
Error/Confirm messages which don't get in the way... Unless the user needs to take immediate action, don't display a dialog. If the error is obvious, fix it for me and then tell me why
Scalable UI. With WPF this is getting easier, but it is annoying if I'm on a large monitor and I have to squint to see anything. Not to mention my click accuracy isn't that great.
UI Consistency.
I know I've been guilty of leaving out printing support in the past. I would never use it, but some of my users do.
drag and drop
clipboard
Good design.
Leave room in your dialogs so if you internationalize it, you have room for longer words (think Italian) and bigger fonts (think Chinese).
I'll add a few myself that have't been mentioned yet:
Non-modal forms that can remain open while other work is done.
Ability to view multi-windows at once (instead of tabs which show only one at a time)
Ability to have multiple views of a single window at once, i.e. split mode, or panes, or actual multiple windows into the same object.
Clean and intuitive.
Clean icons. Good icons. Meaningful icons.
I am very disappointed with a lot of icons inside applications — especially on Windows ;-)
actual consideration for the user seems to be left out quite frequently:
using terminology that makes sense to the programmer, but not the user
organizing the application's workflow for the convenience of the programmer, but not the user
not considering the user's work processes in the first place, and finding ways to help him/her eliminate steps and simplify things
Being able to use drag and drop to customise the toolbar and to be able to remove/hide unwanted toolbars without leaving an unused button whose only purpose is restore/unhide them.
Freezing the application when it's doing something that takes more than a second.
Not showing users what's happening, and not indicating how long it's going to take.
IMO, user name and password login options need work. I understand there are security concerns with each of these options. The risk-trade off is different for each application and needs to be assessed on an app by app basis.
Often forgotten or poorly implemented features include:
Remember Me
Forgot password
If you have a restrictive password policy, give me a hint as to what it is!
Range for # of characters, no special characters, required numbers or capitol letters, etc
Forgot username
If my username is not my email address, give me a hint to your username policy
Kind of too general a question. It would depend on what does the application do. One thing I see often missing from gui applications is an easy way undo mistakes and not only in the object you're manipulating but also on program UI elements. Closing some floating options panel or toolbar by mistake and then having no idea where is the thing enabled frustrates me to no end. Is it under Windows? Or under View? Was it this one? no that one is for something else entirely. Gah! what's it called?
Cycling through links and fields using the tab button.
Left click drag to highlight, right click for context menu with option to copy highlighted text. Found missing from some applications coded in Java.
Windows that snap to other windows and screenboarders. KDE and Winamp do this, and are the ones most famous for it. Why don't a whole host of other applications and DEs do this?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We are currently working on a new version of our main application. one thing that I really wish to work on is providing support for multiple monitors. Increasingly, our target users are adding second screens to their desktops and I think our product could leverage this extra space to improve user performance.
Our application is a financial package that supports leasing and fleet companies - a very specialised market. That being said, I am sure that many people with multiple monitors have a favourite bit of software that they think would be improved if it supported those extra screens better.
I'm looking for some opinions on those niggles that you have with current software, and how you think they could be improved to support multi-monitor setups. My aim is to then review these and decide how I can implement them and, hopefully, provide an even better environment for my users.
Your help is appreciated.
Thankyou.
Few random tips:
If multiple windows can be open at one time, allow users to have them on separate screens. Seems obvious, but some very popular apps (e.g. Visual Studio) fail miserably at this.
Remember the position of the last opened window, and open new windows on the same screen as before. However, sometimes users switch between multiple and single-display (e.g. docking a laptop with an external CRT), so watch cover this case as well.
Consider how your particular users work, and how having two maximized windows simultaneously might help. Often, there is a (fairly passive) window for reference (e.g. a web browser/help) and an active window for data entry (e.g. editor/database) that users switch between.
Do not put toolboxes/toolbars on a different window than objects they operate on (it's inconvenient to move the mouse so far).
Apple's Human Interface Guidelines for the Mac have covered window management on multiple displays since 1987, when the Mac II was introduced with six slots that could all contain a graphics card. The guidelines offer a few good guidelines that you might not think of at first when implementing multiple window support. For example, if a window spans multiple displays, which display should new windows be opened on? There's an answer around Figure 14-33 in the chapter dealing with Window behavior.
Microsoft may have something similar now for Windows developers to follow; if that's the case, check it out and follow their guidelines since you don't want to behave differently than the other apps on the system (or that your users are used to) for no good reason. However, if there are no guidelines, follow Apple's as they're fairly well thought-through and were originally developed through experimentation and research.
Please Please Please. If you remember window positions for multiple monitors. Please detect if the second monitor is connected. I have a laptop that is sometimes docked. It is very annoying when I try to open a window and it opens off screen.
It's annoying when I drag a window to another monitor, and then if the application generates a popup dialog, or spawns another window, if that popup/dialog gets displayed back on the primary monitor.
I haven't developed for multi-monitors, but I think this can be better handled if you position child windows/dialogs centered on their parent window, rather than on the desktop center (which I'm guessing is what happens in the case I describe above).
I'm going to have to a give a nod in dbkk's direction as they captured a couple of the major points that you need to remember.
Also, I would suggestion paying attention to how you use dual monitors and try to keep that in mind as you are developing. Generally you should try to avoid doing the things that applications you work do that annoy you. Also, don't assume that just because the user has dual monitors that they are going to want to work with your application on dual monitors.
The biggest thing that I would stress is keeping track of where the focus is in the application and making sure that any pop-ups occur within that region, one of the things that people seem to dislike the most is having a window pop-up in a different window then the one they are working on.
Definitely keep dialogs near where you clicked to bring them up. Remember what monitor the window is on between sessions. Be aware that if they have less monitors than the last time your app was run that you need to bring the windows back to a visible area. Provide an icon or button to switch monitors. Depending on the type of app it may be useful to be able to easily tile your app's windows on a monitor or on all.
One thing to keep in mind is that the user may have more than two monitors. My main system has six monitors, and I've run 4+ monitors on Linux, Windows, and Mac OS. Many applications--even multi-monitor utilities--will support 2 monitors but freak out over more than 2.
Applications work best when they know about where their windows are and relate to the locations of those windows. And as someone else mentioned, if you're going to remember where a window was, make sure that geometry still makes sense when the user comes back.
If the OS/window system dispatches an event related to the change of screen geometry, handle it if you're doing anything funky.
I think most applications that are well coded generally work these days.