We have written a WPF desktop application for Windows. The application launches on start-up and mostly runs in the background, but has a UI which is accessible via the system tray. Occasionally the app needs to notify the user of something, and so for this, we use the NotifyIcon library to generate notifications. Here is the relevant code:
XAML:
<mui:ModernWindow
...
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:tb="http://www.hardcodet.net/taskbar"
... >
<tb:TaskbarIcon
x:Name="MyAppIcon"
...
</tb:TaskbarIcon>
</mui:ModernWindow>
C# code behind:
using Hardcodet.Wpf.TaskbarNotification
public void ShowStartupBalloon(string message)
{
// show balloon with built-in icon ie 'Info'
MyAppIcon.ShowBalloonTip(Properties.Resources.App_Title, message, BalloonIcon.Info);
}
The notifications appear as small floating windows near the taskbar, but (sometimes, not always) they include the string "microsoft.explorer.notification" and GUID.
We would like to eliminate these as they are confusing our customers; many think some kind of error in the software has occurred. Does anyone know how to suppress that in order to display only the text of the notification we have supplied?
I've experienced this problem as well. From what I've gathered, that bottom text is Microsoft's way of making sure that a user knows the source of a notification, and that random programs can't impersonate a genuine windows notification. The inclusion of a ToolTipIcon (in your case the info icon) seems to trigger this.
As a result, you can remove that text completely by not specifying a BalloonTipIcon, either by not defining the property at all, or defining it as None:
MyAppIcon.ShowBalloonTip(Properties.Resources.App_Title, message, BalloonIcon.None);
The only tradeoff, of course, is that your notification won't have an icon.
Hope this helps.
Show icon with automatic timeout:
public static void ShowBalloon(string title, string body)
{
// Show with icon
NotifyIcon ni = new NotifyIcon() { Visible = true, Icon = Properties.Resources.Icon};
// Timeout is deprecated since Vista
ni.ShowBalloonTip(0, title, body, ToolTipIcon.None);
// Dispose on event
ni.BalloonTipClosed += (sender, e) => ni.Dispose();
}
Microsoft.Explorer.Notification text is shown due to immediate disposal of NotifyIcon object.
So basically if you call
MyAppIcon.ShowBalloonTip(5000);
MyAppIcon.Dispose();
you get the Microsoft.Explorer.Notification.{GUID} instead of AppName in the notification title.
To fix that avoid direct disposal and use what Beni proposed:
MyAppIcon.BalloonTipClosed += (sender, e) => MyAppIcon.Dispose();
Related
Im building a WPF app and i'm trying to check several URL's in the background within a WebView2 window
Altough some urls have popups (which aren't real popups) in the upper left corner like asking for permission to use e.g. the microphone or something.
These popups are getting displayed in full size even if the visibility of the 1x1 pixel big webview is hidden
Here is an example of such a popup in my app:
The black corner is the edge of the app and as you can see the meet.google.com popup is displayed in full size even if the webview is invisible
I already tried to disable the notifications with the new window requested event but this doesn't work because it isn't a new window and it doesn't have a URL or anything.
I also tested many CoreWebView2 settings which made sense,like before no useful results
Does somebody know if there is a setting or something which i have to enable/disable in WebView2 to disable these notifications?
If any further information is required please ask me!
You need to look at the Permissions Requested event for mic and camera.
async private void InitializeWebView2()
{
await webView21.EnsureCoreWebView2Async();
webView21.CoreWebView2.PermissionRequested += CoreWebView2_PermissionRequested;
}
private void CoreWebView2_PermissionRequested(object sender, CoreWebView2PermissionRequestedEventArgs e)
{
Debug.WriteLine(e.PermissionKind.ToString());
e.State = CoreWebView2PermissionState.Allow;
}
I am trying to create an application that will have a tray icon only, and not appear in the taskbar. (similar to Dropbox) I need to create both Windows and Mac version of the application, so I tried using MonoMac to create the Mac front-end.
What is the best way to create a tray-only application in MonoMac?
All the resources I have found say to do one of two things:
Add <key>LSUIElement</key><string>1</string> to the Info.plist file.
Add the following code to the FinishedLaunching event in the AppDelegate class: NSApplication.SharedApplication.ActivationPolicy = NSApplicationActivationPolicy.Accessory;
I have tried all combinations of these two, but it seems that as soon as I try to instantiate a C# System.Timers.Timer, the icon reappears in the dock at the bottom of the screen. Am I missing something about how OSX handles background applications?
What am I doing wrong? Is there a better way to make a background application that has an upper tray icon but no bottom dock icon in OSX?
(This is very similar to this SO question, but that question was from a couple years ago and was never fully answered, so I'm hoping there might be a more complete answer out there.)
Here's the code I have so far:
public partial class AppDelegate : NSApplicationDelegate
{
MyServiceObject currentServiceObject;
public AppDelegate () { }
public override void FinishedLaunching (NSObject notification)
{
// Construct menu that will be displayed when tray icon is clicked
var notifyMenu = new NSMenu();
var exitMenuItem = new NSMenuItem("Quit My Application",
(a,b) => { System.Environment.Exit(0); }); // Just add 'Quit' command
notifyMenu.AddItem(exitMenuItem);
// Display tray icon in upper-right-hand corner of the screen
var sItem = NSStatusBar.SystemStatusBar.CreateStatusItem(30);
sItem.Menu = notifyMenu;
sItem.Image = NSImage.FromStream(System.IO.File.OpenRead(
NSBundle.MainBundle.ResourcePath + #"/notify-icon.icns"));
sItem.HighlightMode = true;
// Remove the system tray icon from upper-right hand corner of the screen
// (works without adjusting the LSUIElement setting in Info.plist)
NSApplication.SharedApplication.ActivationPolicy =
NSApplicationActivationPolicy.Accessory;
// Start running the program -- If I comment out then no dock icon appears
currentServiceObject = new MyServiceObject();
}
}
I found the problem, and it wasn't related to the application settings at all. Evidently, there are some operations that MacOS does not allow an 'Agent applications' to perform. As soon as one of those methods is called, the application is forced to appear in the dock. The code that was tripping up my application was a call to:
System.Windows.Forms.Cursor.Position.ToString()
Removing that line, and replacing it with the following MonoMac method allowed the application to remain hidden:
NSEvent.CurrentMouseLocation.ToString()
I was able to get this working by setting the value of "Application is agent (UIElement)" key to 1 in the info.plist file. Even though it should be a BOOL value, MonoDevelop makes it a string, but setting it to 1 seems to work. You can also set an empty string the for the "Icon file" but it's not necessary.
I have lots of old Windows Forms applications that will eventually be ported to WPF (it is a large application so it can't be done in one sprint), and I have started the process by creating a main menu in WPF. The Windows Forms applications are separate windows opened from this menu.
The Windows Forms applications are opening and working without any problems except the issues I am having with the shortcut and Tab keys. The tab key is not moving focus to the next control, and the Alt key to trigger the &Search button no longer works.
What am I doing wrong?
A partial solution I discovered is to call this from your WPF constructor:
System.Windows.Forms.Integration.WindowsFormsHost.EnableWindowsFormsInterop();
(You need to reference the dll WindowsFormsIntegration.dll)
I say partial because not all key strokes function as expected. Eg, seems to work okay for simple forms.
See this:
http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.windowsformshost.enablewindowsformsinterop(v=vs.100).aspx
I finally managed to fix the issue by hosting the winform inside a WindowsFormsHost control inside a WPF form.
public partial class MyWindow : Window
{
public MyWindow()
{
InitializeComponent();
Form winform = new Form();
// to embed a winform using windowsFormsHost, you need to explicitly
// tell the form it is not the top level control or you will get
// a runtime error.
winform.TopLevel = false;
// hide border because it will already have the WPF window border
winform.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
this.windowsFormsHost.Child = winform;
}
}
Please note that you may also need to hook up the winform close event if you have a button to close the form.
This is by design. Shortcut keys are handled at the message loop level, detected before the Windows message gets dispatched to the window with the focus. That's the reason those keys can work regardless of the focus.
Problem is, you don't have the Winforms message loop pumping the messages. Application.Run() is implemented by WPF in your program, not Winforms. So any of the code in Winforms that processes keyboard messages to implement shortcut keystrokes won't run.
There's no good solution for this, it is pretty fundamentally the "can't get a little pregnant" problem. This code in Winforms is locked up heavily since it would allow CAS bypass. The only workaround is to display a Form derived class that contain Winforms controls with its ShowDialog() method. That method pumps a modal message loop, the Winforms one, good enough to revive the shortcut keystroke handling code. Restructure your approach by converting the main windows first, dialogs last.
Another solution I found to handle focus on the Tab key is to override OnKeyDown like this:
protected override void OnKeyDown(KeyEventArgs e)
{
if (e.KeyCode == Keys.Tab)
{
HandleFocus(this, ActiveControl);
}
else
{
base.OnKeyDown(e);
}
}
internal static void HandleFocus(Control parent, Control current)
{
Keyboard keyboard = new Keyboard();
// Move to the first control that can receive focus, taking into account
// the possibility that the user pressed <Shift>+<Tab>, in which case we
// need to start at the end and work backwards.
System.Windows.Forms.Control ctl = parent.GetNextControl(current, !keyboard.ShiftKeyDown);
while (null != ctl)
{
if (ctl.Enabled && ctl.CanSelect)
{
ctl.Focus();
break;
}
else
{
ctl = parent.GetNextControl(ctl, !keyboard.ShiftKeyDown);
}
}
}
The advantage of this solution is that it doesn't require neither a WindowsFormsHost nor a message pump which can be a hassle to implement. But I don't know if it is possible to handle shortcuts keys like this because I didn't need it.
Check if IsTabStop="True" and TabIndex is assigned. For Alt + Key shortcut, try using the underscore (_) character instead of the ampersand (&).
Using Windows Forms, .NET 3.5 framework, language: c#
I would like to show a popup window for 1 second to notify users of actions that are performed. For example, when I copy a file X I want to show a notification like "Copied file X to File X-copy". Should be shown for a second, then autohide.
You can use a timer. Something along the lines of the following where ShowFloating does the initial display and HideFloating does, you know.
public void ShowFloatingForXMilliSeconds(int milliSeconds) {
ShowFloating();
if (_autoOffTimer == null) {
_autoOffTimer = new System.Timers.Timer();
_autoOffTimer.Elapsed += OnAutoOffTimerElapsed;
_autoOffTimer.SynchronizingObject = this;
}
_autoOffTimer.Interval = milliSeconds;
_autoOffTimer.Enabled = true;
}
void OnAutoOffTimerElapsed(Object sender, System.Timers.ElapsedEventArgs ea) {
if ((_autoOffTimer != null) && _autoOffTimer.Enabled) {
_autoOffTimer.Enabled = false;
HideFloating();
}
}
Also detach the timer handler and dispose the timer in Dispose.
This topic will help you to make topmost window without stealing focus from currently active window.
To complete your solution, in simple case you need to add a timer on your form to make sure the form auto-closes after 1 second and locate your notification window properly (you probably want it in the bottom right part of the screen? - that's a simple arithmetic exercise).
For more advanced solution, you should create NotificationManager class and manage lifetime of your notification message forms there.
Dispite the answers given. I think a message that pops up is somewhat not user friendly. What about using a statusbar link? It's not that evasive (and you can show the progress)
How can I create a Popup balloon like you would see from Windows Messenger or AVG or Norton or whomever?
I want it to show the information, and then slide away after a few seconds.
Edit: It needs to be blocking like Form.ShowDialog() because the program exits after displaying the notification
You can use the notifyIcon control that's part of .NET 2.0 System.Windows.Forms. That allows you to place an icon for your application in the System Tray. Then, you can call the ShowBalloonTip(int timeOut) method on that. Be sure however to first set the text, and icon properties on the notifyIcon for it to work. Small code sample:
private void button1_Click(object sender, EventArgs e)
{
this.notifyIcon1.BalloonTipText = "Whatever";
this.notifyIcon1.BalloonTipTitle = "Title";
this.notifyIcon1.Icon = new Icon("icon.ico");
this.notifyIcon1.Visible = true;
this.notifyIcon1.ShowBalloonTip(3);
}
EDIT: Ok, so notifyIcon won't work for you. My second suggestion would then be to create your own control for this. Actually, I would use a form. A simple form, with no borders, and no control box and just have a timer running so you can set the Opacity for fade in/out. Then, you can easily get the bottom right of the screen using the Rectangle Screen.PrimaryScreen.WorkingArea. Then just show your form at that position.
Don't create a modal (blocking) balloon. Please. A big part of the design of these UIs is that they are not dialogs: they're transient, potentially non-interactive elements, intended to provide incidental information to a user without necessarily interrupting their workflow. A balloon that steals focus and blocks user input would be irritating at best - if you need a dialog, then use a dialog.
The .NET 1.1 Visual Basic Power Pack had a toaster control.