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.
Related
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.
I want to check for changes in the aplication state every time interval, and if it has changed, to open a window, and give the user 10 seconds to press on the window, if he does press on the window, then to allow him to navigate freely in the window, and if he doesn't press, to return back to the window before. I thought to implement it with a thread running in the background and waking up every time interval I want. Maybe there is a better way?
This strikes me as a scenario with lots of potential issues.
How do you stop the "window" appearing at an inconvenient time to the user? (e.g. when they were just about to tap on som.ething)
Why not just raise the notification when the state actually changes? This way you wouldn't need to poll.
What is the "Window" you are displaying? How does it differ from the page it is replacing? Is this a popup or are you actually navigating to a different page?
What is the state that's changing? How is it changing without user interaction?
Can't you notify the user of the state change without a potentially intrusive display of a new "window"?
I agree with #matt-lacey, this could be dangerous and might result in a bad user experience.
With that said, this might work
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
//navigation code here
});
I didn't know you could do a pop-up window, could you elaborate?
I've made a thread that is running at the background and making some work, if it decides that a change is necessary, I want to give the user a chance to react to it, or ignore it.
I'm pretty new to this, so if there is a better way than to navigate to a different page i would love to hear it.
Thanks.
It sounds to me like you want to notify the user that something has happened/changed and give them the option to do something about it, which is exactly what "toast" notifcations are all about. They pop up at the top of the screen to inform the user, and then the user can tap that toast to do something, e.g. when WiFi networks are available, you tap the toast to select an available network.
The Silverlight Windows Phone Toolkit includes the ToastRequestTrigger that you use to display toast notifications. The Windows Phone Developer Guide from the patterns & practices team gives examples of using the ToastRequestTrigger. You will need to implement the tap handling yourself in the toast content, but this should be simple enough.
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.
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).
We are using a software program at our school to enter IEPs (Individualized Education Programs). When entering goals and objectives for a student, users are provided with a Save and a Close button. Close is meant for users not wishing to save the goal they just chose. However, our users are sometimes wanting to back out of the screen and close the Window by clicking on the X in the upper right hand corner. Unfortunately, this somehow corrupts data and the user has difficulty later entering goals. The software company tells us to educate our staff not to click on the X and that there is no way to disable it. The software is web-based and our school has standardized on IE7.
If it's web based, then you're probably just running a webpage in Internet Explorer. If that's the case, I'd recommend IE's kiosk mode.
If you need something a bit more heavyweight, Public Web Browser is a good and cheap choice that I've had good experiences with.
There is no way to disable the close button on the window (can you imagine!? ad popups that never go away! eek!).
However, you can catch it and do something useful (like click the "close" button on the form). See:
http://blogs.x2line.com/al/archive/2004/09/15/561.aspx
A lot of browsers have a full-screen mode (F11 in Firefox), where they take up the entire screen real estate, hiding any other UI elements, including the top bar (at least for Windows, dunno about *nix). This is a very simple solution, but afaik there's no way to disable the [x] for windows in general, you'd have to find a browser that does not use the default Windows look and doesn't implement it's own [x] in the corner.