new Windows 7 hides systray icons by default.
what is the recommended way to show information to users now?
I need to have a small clickable icon visible to user so user can access my "tool" anytime. Should I use the gadget to show my GUI instead? Can it communicate with my Delphi app somehow?
Without more information it's a little difficult to provide a recommendation.
However, I would imagine that a sufficiently important tool, the user would simply keep minimized. They could then use Jumplists to access quick functionality.
For example, Live Messenger uses this setup on Win7.
If your users really like your icon/application they can always choose to not hide your application.
The only difference is that only the user can choose which icon is shown, instead of every application claiming it's "real estate".
In my opinion this is a good functionality and if I were you I wouldn't change the application, just provide a first run GUI which explains how to make your tray icon visible in windows 7.
The entire reason why change was made, was to stop programs like yours. If you need to show information, go ahead and do so. But the notification areas ("systray") is not where shortcuts go. For that, you've got the start menu, desktop and/or the quick launch bar (and please let the user decide).
Related
I'm developing a app that will be available at a regional fair and the public will use it to quickly download "perks" to theirs pen-drives. BUT when you move your mouse to the top-right corner of the screen a "menu" appears (there's a similar thing on tablets) and it enables the user to quit/switch-out-of my app, and that I can't allow! How do I block that?
You have to wait for Windows 8.1 i.e. 18th October. 8.1 offers such thing to manage. Moreover it also offers kiosk mode. Through which you can allow only one app to be open on top most.
Source
This is not under the control of your application, it's a feature of the operating system. And as far as I know, there's no way to block it. Typically such changes would be done through group policy settings, but at least in Windows 8, there's no such control available. I'm not sure about Windows 8.1, although I haven't stumbled upon any mention of such features there, either.
Also, this is not the only way for the user to switch out of your application. He could also drag the app down from the top and close it or go to the lower bottom corner to open the start screen, if he's using the mouse. The keyboard would give him even more options, of course.
I have a friend who's working at a company that offers pretty poor support for its developers (scoring a 1/12 on the Joel Test).
Their build process is locked down pretty tight, and depending on the size of project it could take 40+(x2) mouse clicks to deploy. So I thought, "Hey, why not automate it the clicks using the win32api?" (Specifically using Python). I've got him a real nice tool that works just fine except for one issue - the tool that they use has a navigation pane that may or may not be open.
You can open and close it with a button press, but I'm not sure how I could make sure it was either open or closed. It's irrelevant to the build process - the only problem is that it alters where the mouse needs to click on the screen depending on its open status. The application is written in .NET and it exposes a function call that applications are able to use to toggle the panel, so I've been looking around for ideas and so far I've got two of them:
Attach to the process via a debugger and execute the function call somehow.
Take a screenshot at the location of the panels titlebar (which I've got through the win32 API and doesn't appear to change regardless if the panel is hidden or not).
Is there an easier way to figure out the state of this panel? The developers are given an admin account on their machine in addition to their regular account, so I can entertain ideas that require admin access, though I don't think that should be necessary?
UPDATE:
It looks like there's a button that can close the pane. In UIAVerify something shows up as "text" "Navigation" "btnClose". It says its AutomationId is btnClose but it's a ControlType.Text
What technology is this panel built from? Is it standard GDI or WPF? If its GDI, it should have a HWND. You should be able to find this HWND through either a class name or window title. Once you have the HWND, you can get its width.
If its built with WPF, er, I have no idea, but Snoop does this kind of thing, so I know its possible.
Is there a way to create a custom Windows 7 logon screen and UI? I don't mean just customizing the picture, I mean something in the sense of a flash splash screen on a website. And then having the whole UI customized in the sense that, instead of a start button, I have can have like... a plus sign that opens up a customized start menu.
Is there anything in the Windows GUI library that will enable this? I know quite a few languages except for assembly, not sure if it would require that anyway.
In other words, if you go to www.sony.com you see how it loads up? Is that possible in a Windows environment? If not, where or how could I do it in another environment? Thanks!
I need to know if the user has hidden an icon added by my program to the system tray area.
Is it technically feasible?
UPDATE
My program - yowindow displays the current temperature in the system-tray icon.
I want to spare the server load by not auto-updating the weather for the users who don't see the tray-icon.
No.
And what would you do with this information, even if you had it?
(caveat - I guess you could do a screen-grab, work out where the taskbar is, figure out where the system tray is, "parse" out each icon, then bitmap compare each against your own icon. But really...)
It might be worth your while looking at this related question
Based on first Edit to question
I can see your point. But look at it from the windows API designer's POV. They provided a facility for icons to be created in an "always visible" manner. And every man+dog went ahead and put an icon in there, on the presumption that the user would always want to know about their product (please note, I'm not claiming that you're in this group here).
They've noticed this runaway behavior, and whilst they can't now take away the ability to create these icons, they want to give the user control.
Now we come to the problem. Imagine, for a second, that you're a less than enlightened developer. And if you detect that your icon has been hidden, you pop up a message prompting the user to un-hide your icon. Maybe you do this once per login. Maybe you do it every half an hour. It's just a general level of user annoyance, similar to having 40 icons appear in the tray, when the user doesn't care about most of them
The question is - if you were designing an API to allow developers to discover whether their icon is, in fact, hidden. How do you allow your benign usage, whilst preventing the behavior in the previous paragraph? Spend a few minutes trying to pretend to be a windows API designer, and try to write the necessary function(s) (for the sake of argument, assume the annoying developers aren't willing to implement the IAmEvil interface, or whatever, or would be willing to implement the IOnlyDoGood interface...)
Hopefully, your icon is useful, and users will either a) show your icon, or b) remove your application (if it's not doing what they want/need)
There is no API function for that as far as I know, and there's no good solution to the problem. You could directly after the installation show a message from the tray telling the user that the icon may be hidden. Not that it will help, but it's all you can do. I've seen programs that bug the user by periodically showing that message but this is really NOT a good thing to do.
In a fairly graphics intsensive application the requirements state that it should default to full screen mode even though the application is running under Windows. I know many games do this but I find it annoying. The default IMO should be to open in a window rather than full screen mode. I am proposing the first time the user runs the application they should select the default behavior. Am I wrong?
I think the annoyance-factor depends a lot on what the application tries to do.
If it is some utility that I might start while working in 5 different applications and it forces its fullscreen-ness on my, then I'd get highly annoyed.
If it is a specialized application that helps me with the entire workflow of a given task (so that I never or rarely need any other apps open at the same time), then fullscreen might actually be a valid default.
Whatever you do, just make sure that toggling the startup behaviour is very discoverable. Because no matter which way you'll go, some of your users will disagree with your decision. And for them it should be very easy to change to their prefered way.
I would follow the requirement the first time the application is launched. I would also provide a simple way to switch from full screen to windowed, for instance by pressing ESC (and another way to go back to full screen). Then I would store the mode when quitting the application and restore this mode at next launch.
Before doing the opposite of what your requirements say, I'd have the requirements changed.
However, what about giving the user the choice at install time?
The window at first-start-up should default to the optimal size for the largest proportion of users. For a graphics-intensive full-featured app, that may very well be full screen.
As for individual user preferences for window size, it seems to me most users won’t know if they want full screen or not until after they’ve started to use the app and see how much screen space they need and how much they use the window in conjunction with other windows. Asking them which size they want at install or first-start-up could thus be annoying and even confusing. It’s better to put such a setting under Options/Preferences.
Perhaps the best thing to do is save the window status on exit. Users who like it non-maximized thus only have to non-maximize it (and size it) once and then forget about it. The only consideration is to have some way to reset the window to the default (e.g., Window > Standard Size menu item) for novice users who accidentally resize or reposition the window to something bizarre and don’t know how to get it back. Alternatively, you could have a Window > Keep Sizes and Positions menu item for users to explicitly save the window status across sessions.
Go back to the requirements writers and ask them if they have considered non-traditional monitor setups, such as:
30" or larger monitor. Do you really want your app hogging up all the screen real-estate?
Multiple monitors. Which monitor will you run on? Can the user move your app from one monitor to another? Can your app span more than one monitor?
Virtual desktops. Can the user move your app from one desktop to another? Can they switch desktops while your app is running? Can your app span more than one desktop?
Such setups are increasingly common, especially large monitors. IMO, full-screen mode (the default for many older Windows apps) is becoming less and less useful.
The problem with presenting the user with the option of initially selecting fullscreen / vs windows is that they haven't used the software yet. How can they make a decision on which is better for them, without experience?
I would run the app in whichever mode provided the best user experience and then offer an option to change it both in the Preferences and though a hint while starting up the application for the 2nd time.