ShowBalloonTip(): message appears with delay - c#

In Windows 7 64 bit, Visual Studio 2010 Express, C#, NET 2.0, Windows Forms, I have an option in a context menu that hides my application (or minimizes it) to an icon in the notification area. The notification icon is always visible, as the application does not appear in the taskbar.
this.WindowState = FormWindowState.Minimized;
this.notifyIcon.ShowBalloonTip(10000, Application.ProductName, "To restore ProgramName, left-click its icon. Or right-click for the menu.", ToolTipIcon.Info);
However, the message is display with more than 10 seconds delay. This is not good, because I want to inform the user immediately from where he can restore the program.
How can I solve this issue? Thank you.

I assume you mean that when you minimise your application, there is more than 10 seconds delay before the balloon tip becomes visible?
I'm having problems replicating your error, and I've never had this problem in the past. The problem may not be with your code in this particular function, but maybe elsewhere? Are you handling a lot of operations in the SizeChanged event (or something along those lines)? Or perhaps you have a lot of other applications hogging resources in the notifications bar?
Sorry I can't be of much use, but more information may help weed out your problem :)

Related

How can a screensaver continue to draw over the desktop in Windows 8?

I’m developing a screen saver in C# .NET4.0 on VS2010 which needs to do a fair bit of processing before it actually shows screens (fairly complex database access). This is fine because the user is unaware that this processing is going on and then the full screen forms kick in when everything is ready. That is, unless we are running on Windows 8.
Searching on the Microsoft Community (http://answers.microsoft.com/en-us/windows/forum/windows_8-desktop/bubbles-screensaver-has-black-background/e0807324-5ca6-4abe-b6ba-716848b41ff5?page=4) reveals that a design change was made in Windows 8 that prevents screensavers from drawing over an image of the desktop. Any screensaver that previously drew over the desktop will instead draw over a plain background using your chosen “metro” background colour. Experimenting reveals that this background kicks in immediately the .scr file launches i.e. before any forms can be displayed. Hence tricks like displaying forms minimised or with 0% opacity don’t work because this simply reveals the plain background underneath.
The best I’ve been able to come up with is to display full screen plain black forms as first action when my code starts i.e. before any database processing or other screen construction takes place. Why try to replace a plain screen with another plain screen? Well, because the default Windows background colour seems to be blue. That’s blue as in BSOD blue which looks kind of alarming when it kicks in. So the best I can do for a Windows 8 user experience is a quick flicker of blue followed by 3-4 seconds of plain black before screens are populated with something meaningful.
This new behaviour from Microsoft is apparently “by design”. The fact that it doesn’t manifest itself in Preview mode is apparently an error which one supposes MS will tidy up later.
So my question is does anyone know any way around this so that I can continue to have the desktop showing until screensaver forms are ready to kick in?
I struggled quite a lot with a similar problem regarding this awkward design decision in win8.
I the end had to compromise but my search continues for a a bullet proof solution, when I have time.
Now what I ended up with is running a batch file after the monitoring system starts and have thread detect idle time and run that batch again.
#start /wait Bubbles.scr /s & rundll32 user32.dll,LockWorkStation
What this does is:
starts screensaver preview in fullscreen (this works in win8) and waits
on user action lock screen is show and user prompted for password
As I said it's a compromise until a find something better. Hope it helps
Updated to win10; try to use that cool scr and found same issue;
Try to trick ms restriction and found only one very long solution:
enable logging of screensaver invoked events;
here instruction via gpedit: https://superuser.com/questions/538146/run-a-batch-cmd-upon-screensaver
now you will able to start other comand or app when screensaver starting;
goto C:\Windows\System32
copy Bubbles.scr and rename to Bubbles.exe
then config task to run C:\Windows\System32\Bubbles.exe with argument /s (administration->taskcheduler)
use some windows screensaver and config to use 1 min or more; (or use 'runsarver' with empty options from upper link or create your own empty.exe and rename to .scr and install with right menu, etc)
Found cool app to customize hidden screensaver features: http://winaero.com/download.php?view.8
(work with small bugs but work as needed under win10)
All work fine one cons checkbox to lock PC must be unchecked;
If needed create own app to run Bubbles and on exit lock PC or bat file as above, etc;
hope people will have fun with my solution :)

Detecting raised-event at OS-level (OS Appearance)

I have what seems to be a common problem. I am running Windows 7 Home Premium on one of the most awesomest computers (when it was bought last year) and certain visual effects just automatically turn themselves off.
My average user experience rating is high, so it doesn't explain why this happens. The only feature that ever gets turned off is the 'Show window contents while dragging' option. And it really annoys me.
There are currently no working solutions to this problem online. Other than to "there must be a conflict with another app installed on your machine."
And yes, I do know what app is causing this conflict. It's my bloody Internet Provider's software - you know... that app that you absolutely MUST have open at all times when you're connected to the net.
So, I had a thought. What if I could subscribe to an event so that my app that runs in the background will detect when this 'show window contents while dragging' option is turned off - and then my app will simply turn it back on again.
When I do this manually, it seems to stay in effect for about an hour or two, then it gets switched off again.
Is it possible to handle these types of events, and re-start certain visual effect features? If so, are there any resources on this?
I have not been able to find anything on this sibject yet.
Yes the WM_SETTINGSCHANGE message is sent to all windows when a system setting is changed. Then you can call SystemParametersInfo with SPI_GETDRAGFULLWINDOWS to determine if the "Show window contents while dragging" is disabled and use SPI_SETDRAGFULLWINDOWS to enable it.
So all that you will need to do is create an application with a form (that can even stay hidden) and override the forms WndProc and handle the WM_SETTINGSCHANGE message and call SystemParametersInfo using p/Invoke. The p/Invoke definition for SystemParamtersInfo is available at pinvoke.net
Altough what may be easier is change security on the HKCU\Control Panel\Desktop\DragFullWindows registry value so that it can't be changed.

Alternative way to notify the user of an error

I have a winform software that communicates with hardware through a protocol.
Sometimes error in communication happens and i would like to notify the user. Errors could be for example: timeouts, crc errors, physical disconnection etc...
I have a communication window in which i show these errors, but by default this is hidden. The user can open it though the menubar.
Popups are annoying to the user (and to myself) so i would like a un-invasive way to notify the user that an error has occurred. Perhaps a info bubble like when XP tells you updates are ready for your computer? I know that NotifyIcon can help put things in the system tray, which i do not wish to have. I'd rather keep it within my MDI.
I'm open to other creative ideas as well.
There are several alternatives that can be employed when an error occurs, each with their own advantages and disadvantages:
MessageBox popups
Display a message box popup to the user.
Advantage: since it is modal, the user has to acknowledge the error to continue.
Disadvantage: since it is modal, it interrupts the user from whatever they were doing. Multiple errors are also inconvenient, requiring multiple confirmations.
Show the communication window
If your existing communication window is hidden, display it to make the logged error visible.
Advantage: uses the existing familiar communication mechanism.
Disadvantage: if the user does not really care about the errors, it could be annoying that the communication window continually reappears.
Status bar messages
Show messages in the status bar of the application.
Advantage: will always be visible on screen, but is "out of the way" of the main window.
Disadvantage: hard to display multiple messages and may be missed by the user.
Balloon notifications
Show an Outlook/MSN Messenger style notification message near to the notification icons.
Advantage: is obvious enough for a user to notice, but does not necessarily require a notification icon. Could also collate multiple messages into a single popup.
Disadvantage: could be annoying to the user.
Notification icons
Show a notification icon (perhaps with a balloon notification).
Advantage: is obvious to the user, but still unobtrusive.
Disadvantage: is yet another notification icon to clutter up the user's desktop.
Personally, I would choose option 2 as it requires the least amount of effort to achieve. If it is unacceptable once people start to encounter it, review the other alternatives.
For examples of balloon notifications that do not require a notification icon, see this for Windows Forms and this for WPF.
One (relatively) common paradigm is to place a message on the status bar ("[x] New Messages"), and make the appearance of the message window a user action.
If your MDI window is open/visible, then you could have a comms status icon on it - this would be green when everything is fine, orange for warnings (like corrupt packets have been detected, but comms is still working and the system has recovered), and red for errors (like no decodable comms received for 5 seconds). This allows it to be fairly subtle when things are wokrking, but quite noticeably "different" is a problem occurs.
For a serious error (e.g. disconnection) you may want to get more "invasive" because there comes a point where not bringing the problem to the user's attention is worse than bothering them with the error report.
If your window is not guaranteed to be visible then (despite your dislike of the idea) a system-tray icon (to show this status) is a standard and rather clean solution - it can be permanently visible or simply appear when it is relevant, it's about as non-invasive as you can get while still bringing information to the user's attention, and easy for the user to check periodically to reassure themselves that they have a "green light".
An alternative to visual indicators is to use audio alarms.
(For example, we use a monitor on our build server. It simply has a green icon when the builds are good, and a red icon if a build has failed. This is perfect, as it doens't bother me at all but I can check the build status in an instant.
Alternative example: I have an email app that shows an "envelope" icon in the system tray when I have new email, and nothing if I don't. In practice with this system I notice pretty soon (within a minute or two) when mail has arrived, but I am not bothered by constant popups or message boxes.
I think these are both examples that show how much better a system tray icon is than a popup or balloon window. Popups are irritating and with most of them if you aren't watching when they appear, you miss the information. I'm forever spotting popups just as they disappear and then having to open the app to find out if they were telling me anything useful. Which usually they weren't. The same goes for audio notifications: I keep hearing random noises from my IM application and wonder what the heck they mean).
Depends on your scenarios: If the event requires user interaction to resolve, then a modal dialog may well be the best approach because you can't continue until the user, for example, inserts the device into a USB port (or whatever).
For other unusual notifications that the user may need to be aware of but may not disrupt the workflow, I suggest using an in-app popup-toast or updating the status window.
If the user doesn't need to change/interrupt what they're doing, then don't warn/notify them: your device and app should "just work" - the user should only be interrupted if there's something that truly requires their attention or that will cause them disruption "soon".
this put a small red circle at rightside of control. its kinda datagridview cell erroText style
var errorProvider1 == new ErrorProvider();
protected void textBox1_Validating (object sender, System.ComponentModel.CancelEventArgs e)
{
try
{
int x = Int32.Parse(textBox1.Text);
// Clear the error.
errorProvider1.SetError(textBox1, "");
}
catch (Exception ex)
{
errorProvider1.SetError(textBox1, "Not an integer value.");
// additionally, if you wantto prevent user leaving textbox
// until he satisfies condition. uncomment below.
// e.handled = true;
}
}
From: Microsoft

C# Application Not starting minimizied

I've built a C# app that I want to start just in the notification area. The icon appears when it is run, and it does not appear in the task bar (due to ShowInTaskbar = false & WindowState = Minimized). However when it first runs I can still alt-tab to it. Is there anyway to prevent this behaviour? Or have I missed a setting somewhere?
Thanks,
Psy
What you are seeing is correct behaviour, Alt+Tab will restore minimized windows.
It looks like you want a tray application, but be a bit more specific.
Take a look at this question.

How to bring Windows Taskbar on foreground while running maximized?

I've got an app running maximized in a borderless window and need access to the windows taskbar on a given user event.
How would I bring the taskbar in foreground in .NET while running maximized?
Also an hint with regards to how to make it reliably go away wouldn't hurt! :)
EDIT: please note that I don't want the taskbar always on, I want it popping up on foreground just on a given user event, and then I want it to go away at will!
Um, don't run fullscreen? Maybe run maximized? Fullscreen app with taskbar is not a standard UI pattern.
What you could try doing is run maximized without the UI chrome (borderless window). Would let the taskbar in on the fun while still looking like a fullscreen app.
Interestingly enough, your desired solution seems to be the problem that caused this question. See my answer there. You may have to experiment a little with setting the FormBorderStyle and WindowState properties in a certain order, and try to minimize disturbance for the user.

Categories

Resources