Develop Reference

Tray NotifyIcon missing if application starts with system

I have a C# (VS 2012 Express) targeting .NET framework 2.0 which uses the NotifyIcon component to create a tray icon.
There is a shortcut to the application in the users Start Menu\Startup folder which results in the icon appearing in the tray when windows starts, most of time.
In some situations however, the executable launches on system startup but the icon is missing from the tray. I don't a have a set of reliable steps to reproduce this issue however.
From reading this article, it looks like I should be listening to the shell started event and re-drawing my tray icon, however I'm unsure how to go about doing this, as .NET is managing the low level calls for me:
http://msdn.microsoft.com/en-us/library/windows/desktop/cc144179(v=vs.85).aspx
Any pointers would be greatly appreciated. Thanks!
Update: This problem only appears to happen when I have setup Windows to auto-logon to the default user account. If I manually logoff and then logon again my icon appears correctly.
Update: It appears that if I manually close and restart Explorer.exe, the icon is correctly redrawn.

I solved this problem be toggling the visibility of the NotifyIcon component (from false to true) at the end of my form constructor (after calls to InitializeComponents).

Form Constantly Turns White in Designer

The main form of my application constantly turns white in the designer when I perform the following steps:
1) Open form in design mode (All controls are visible at this point)
2) View source code for form
3) Switch back to design view
After performing the steps above, there is nothing visible in design mode for the form (not even the form). I only have this issue with one form in my application and, unfortunately it is my main form where there is a lot of logic. The workaround is to always close the form and reopen it in design mode show that all the components are visible again. I have experienced erratic errors with the designer when I am low on available memory but, this form always produces this symptom and is the only one. Any ideas as to what is causing this? I guess I could always create a new form and try moving all the controls and logic over but, I'd prefer to avoid the work if there is a simpler option.

The diagnostic is that the Paint event or OnPaint method of a control is misbehaving. These methods run at design time so you'll get an accurate visual representation of the control, the way for example that you can see the Image property of a PictureBox at design time. When such a paint event gets stuck in a loop then the entire form stops rendering properly. Beyond a simple bug, the typical reason is that the code is getting confuzzled by the non-standard runtime environment in design mode. You use the DesignMode property to ensure that such code won't cause trouble and is disabled in design mode.
Finding the misbehaving code is the challenge, especially when these are not controls you wrote yourself. Short from removing controls one by one to find the troublemaker, you can use the debugger by starting another instance of Visual Studio and use Tools + Attach to Process to attach to the first one.

From personal experience, I can confirm that this is an occasional issue in both Visual Studio 2003 & 2005 whether VB or C# is used. We patched both versions to the latest service pack and even got hotfixes directly from Microsoft, neither of which resolved the issue.
In the case of VB in Visual Studio 2003, the disappearance of the controls also removed the underlying designer code so we kept having to restore the deleted code from our version control system. Very annoying - as we'd often lose code changes and have to start over.

You defiantly should check the next link:
https://weblog.west-wind.com/posts/2019/Feb/14/WPF-Hanging-in-Infinite-Rendering-Loop?fbclid=IwAR23ZnUrz7buVpFLXOX2qQin1WcifQ6h280EO25URO74NTGDkTedx1TDRb4
here's a quote from the page:
Using the StarDefinitionsCanExceedAvailableSpace Override This setting
overrides the new GridRendering behavior and basically lets you run
with a .NET 4.7.x target in your project, but keeps the old behavior
that was used in previous versions.
There is a configuration setting that can be set in app.config for
your application:
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true"
/>
</runtime>
</configuration>
I can verify that using that switch lets me run 4.7.1 and not see the lock up in any scaling mode. After I
had my running version in 4.6.2 back, I once again moved up to 4.7.1
in a separate branch to try this out and sure enough the switch made
the application run targeted with 4.7.1. So there's a hacky
workaround.
It's a workaround though. This 'fix' according to Microsoft improves
grid rendering allocations, providing more precise sizing and also
improves performance and reduces memory usage. On paper this is a
great improvement, but... well, side effects 😃
I suspect this issue is not wildly common as there was not very much
info to be found about it. I think Markdown Monster makes this issue
come up because the startup sequence has a lot of window manipulation.
MM uses the MahApps UI framework which uses Window Animation and extra
rendering frames for the main window, and MM itself moves the window
offscreen for initial render and adjusts window sizing based on screen
sizes and DPI settings if the window doesn't fit on the screen or
would otherwise be offscreen. IOW, there's a bit of gyration to get
the initial window onto the screen that is more likely to hit this bug
than a simple WPF form.
So I doubt that every application needs to worry about this, but if
you have a 4.7.x WPF app it might be a good idea to try it out at
various resolutions and scale levels just to see how it fares.

WinForms application becomes randomly unresponsive

We are building a WinForms based app (using .NET 3.5)
Recently i have encountered that when performing one of our application's main workflows, the application will become unresponsive in a matter of seconds, failing to properly render the UI (Shows the "Program is not responding" message).
We have reduced the issue to a suspected line of code that adds a tooltip to a label control:
ToolTip tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
I have spent the past 2 days figuring out what in this code could code any issues with the UI thread, but failed to do so.
My question is -- is it possible to use a performance profiler to gather information about code such as this? Note that the ToolTip class belongs to WinForms and i do not have the source code available for it.
Removing these lines seems to solve the issue completely.
I would like to reduce debugging efforts in the future, as this issue can manifest in other locations of our codebase.
EDIT:
The only similar reported issue i could find was this: WinForm ToolTip.SetToolTip is Hanging my application :(

You could use a program such as JetBrains DotTrace to see what is happening that actually causes the program to halt

I have the same problem, except I use a ToolTip object placed using the designer and then in the Popup event of the ToolTip I set the text for the ToolTip.
The problem only occurs on Windows 7 64-bit (I don't have a possibility to test 32-bit Win7), on 32-bit Windows XP, this works fine.
edit: i guess there was some recurrent calling of the popup event, because when i moved the tolltip setting to other place of my code, it works OK.

I know that this is an old question, but the hanging still happens on Windows 10 64-bit edition. On Windows 10 32-bit everything works fine. I have not looked at the .NET source code, but it must be a wait or something. So to overcome this problem I added the following workaround:
this.Invoke(new Action(() =>
{
tooltip = new ToolTip();
tooltip.SetTooltip(label, "something");
}
));
I was already calling this from the main thread, so according to MSDN documentation this doesn't make sense, but it releases the wait lock or something.

ShowBalloonTip(): message appears with delay

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 :)

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.