My Application Icon Beeps In the System Tray (URGENT if you can help...)

[MMock]

I am developing a Windows Application which of course can be minimized.

If it's minimized and the user clicks on the icon in the system tray and it beeps, does that mean it's busy and can't restore at this time?

Here is my theory. Every 30 seconds a timer pops so that grids can be refreshed. It's a customer service application so all day long we have to work with close to real-time data. Very recently to this application I added a check to see if a new version is available. It's a click-once deployment so I am calling:

ApplicationDeployment ad = ApplicationDeployment.CurrentDeployment
info = ad.CheckForDetailedUpdate()

to see if there's an update. Those calls take a few seconds. Enough so that I added a wait cursor when I am executing them.

If I take that code out and I minimize the application and I click on it to restore, it still beeps but very occasionally. Probably because I am clicking the same time it is busy refreshing data? But it is no longer taking the time to check for the new version

But here's the odd thing, I added a flag so at the top of RefreshLoadedData() I can set this flag (bBusyRefreshing) and I turn it off when I'm done refreshing, and if I come into RefreshLoadedData() and it's on, I just get out.

But the beeping is still happening.

I call RefreshLoadedData() when the 30-second time pops and also when Form_Activated() fires. And at other times when a button is clicked but obviously you can't click a button if the app is minimized so that's most likely irrelevant.

Any idea what could be wrong?

[MMock]

I think I mean Taskbar.

[si_the_geek]

If it's minimized and the user clicks on the icon in the system tray and it beeps, does that mean it's busy and can't restore at this time?

I expect so, and it sounds like it based on your description of removing the new-version call.


It sounds to me that the extra work would be better in a separate thread (perhaps a BackgroundWorker), and that is likely to eliminate this issue.

[MMock]

Why doesn't my flag work?

[MMock]

I should also add, because it is perhaps relevant, that my application allows more than one instance to be run. I am bringing this up because StackOverflow conversations mention it in light of similar issues with an icon in one's taskbar. But I am still reading so I don't yet have a good handle on the issue.

At first I wanted to refuse additional instances. Then my users said they needed them. So I am discovering if the application is already opened and I tell them they are starting another instance.

        // 03/30/17 Added a mutex which is a synchronization primitive that can also be used for interprocess synchronization (!).
        // http://stackoverflow.com/questions/6486195/ensuring-only-one-application-instance  
        // https://msdn.microsoft.com/en-us/library/system.threading.mutex(v=vs.110).aspx
        private static Mutex mutex;

        private static bool AnotherInstanceIsRunning()
        {
            bool bCreatedNew;
            mutex = new System.Threading.Mutex(true, "this application", out bCreatedNew);
            if (bCreatedNew)
            {
                // It's the application's first time up.  Let it continue;
                return false;
            }

            if (MessageBox.Show("This applicatin is already running.\r\n \r\nIf you did not intend to start another instance of it, hit Cancel to stop this run.  OK will continue with a new instance.\r\n\r\nIMPORTANT: If you are getting this message because you are updating to the most recent version, hit OK", "Application Is Already Running", MessageBoxButtons.OKCancel, MessageBoxIcon.Exclamation) == DialogResult.OK)
                return false;
            else
                return true;

        }

[si_the_geek]

I'm not aware of any issues with the mutex etc, but it is worth investigating.

Why doesn't my flag work?

It sounds as if your flag is just ensuring that RefreshLoadedData can't run twice at the same time... that wont help if the application is too busy to respond (and I'm assuming it is).

[MMock]

I also have this which I am suspecting:

        [DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true)]
        private static extern bool SetForegroundWindow(IntPtr hWnd);
        /// <summary>
        /// frmStatusDisplay_Activated() - Written 05/15/17, better late than never!  I am testing cmdExitFU_Click() in frmJE and we want to return here and see the FU we just created in the grid.
        /// 06/06/17 - Then why did I comment out RefreshLoadedData()???  Restoring.
        /// 06/09/17 - But maybe we want qryCSFUToday, now that I've implemented it...  But if we just call Refresh, doesn't it do the FU's automatically?  Taking out that line.
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void frmStatusDisplay3_Activated(object sender, EventArgs e)
        {
            if (fg != default(IntPtr))
            {
                SetForegroundWindow(fg);
                //MessageBox.Show("Set the foreground window");
                fg = default(IntPtr);
            }
            // Removed.  See comment in header.
            //qryCSFUTableAdapter.Fill(dsFollowUps.qryCSFU);

            // 10/05/17 - Put this back!
            RefreshLoadedData();
            //RefreshLoadedData();

            
            
        }

I put the SetForegroundWindow() call in because of this thread

I don't even know what this means but it's how I am initializing fg: internal IntPtr fg = default(IntPtr);

[MMock]

I believe I've ruled out that code I was suspecting because I commented it out and I still got the beep.

[si_the_geek]

It shouldn't have any effect on your application at all, because it just tells Windows (very quickly) to activate another window.

I strongly suspect that using another thread for the 'slow' work is the way to solve it.

[MMock]

Yes you are beginning to persuade me. I had to see for myself first, though! I've commented out some code here and there and am still having the issue.
I am going to try one more thing, and that is if I am not refreshing data at all, does the beep happen? Because if no, then I'm sold.

[MMock]

No, it didn't happen! I put in code to check if it's me running and if so don't refresh:

        void RefreshLoadedData()
        {
            if (Globals.Variables.CurID == "67")
                return;

I have to ask one last question. This application was a VB6 application. The problem doesn't happen there. Which makes me worry that when I ported the code to load the grids my .NET queries are more inefficient than in VB6. So am I putting a bandaid on this and I should see why it takes so long? Or is VB6 so different from .NET that that wouldn't be why, it's not an apples to apples comparison?

[si_the_geek]

I strongly suspect the difference is about Timers... I have a vague memory (which might not be right) that the VB6 timer used a separate thread (but only when compiled). There are different types of Timers in .Net, and not all of them use separate threads.

There are also many differences in how the frameworks behave, including in terms of application focus etc, which may well have an effect here.

[MMock]

OK, I think what i am going to do is put my code IsNewVersionAvailable() in a thread. I added it yesterday and it is a lot different than how the VB6 app did it. All the other code in RefreshLoadedData() has existed for months and months so I will leave it alone in the main thread. I believe on occasion the user could still minimize the app, click it in the taskbar and get a beep, but I believe if he retries it will then restore. It's a crap shoot - how often is the user going to minimize the app and how often when it is minimized will he make a request of it that it is too busy to respond to? I'm betting on not often enough to make people mad at me.

Thank you!