0

Context:

I'm developing a screensaver in C# with VS2010 .NET 4.0 on Windows 8.1. It's quite "busy", accessing a database on initial load and doing some image processing before displaying to multi-monitors.

Issue:

In most cases the process shuts down cleanly either a) on mouse/keyboard movement in /s mode or when desk.cpl is closed in /p mode. A problem arises thought when I run in /p mode (desk.cpl open) and then I instigate either "settings" (/c mode) or "Preview" (/s mode). Once these new processes are closed the /p mode returns as you would expect but when desk.cpl is closed the /p mode process continues to run. This is intermittent however - sometimes it closes, sometimes it doesn't.

In /p mode I explicitly don't close the form on mouse movement etc as this is not appropriate for the desk.cpl preview window. My assumption therefore is that desk.cpl would kill my process but this doesn't seem to be happening consistently.

Question:

How can I ensure that /p mode will close down consistently?

Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
ifinlay
  • 621
  • 1
  • 7
  • 24
  • This needs to get started by you using a debugger to find out what code is still running. Tools + Attach to Process, Debug + Break All, Debug + Windows + Threads. – Hans Passant Feb 23 '14 at 11:50
  • Thanks @Hans-Passant. I should have mentioned in my original question that I have already inspected with debugger. I found that normal processing was continuing but of course screen updates were not being displayed because the preview window was gone. Normal processing consists of a system.timer which fires every 8 seconds. This calls form methods (just one in the case of a preview) which fetch an image from a file, do some processing on it and then updates the form background. – ifinlay Feb 23 '14 at 12:36
  • Well, if you can't go through it go round it as they say. I've managed to get the process to close consistently by using GetParent periodically to see if the parent window has changed. When it is no longer equal to the preview window handle that was passed to the screensaver initially then the desk.cpl screensaver panel must be gone. When that happens it's safe to close the process. I'd still like to know why desk.cpl doesn't consistently close the process though. I'm concerned that there may be something I've left untidy here. – ifinlay Feb 23 '14 at 15:44

1 Answers1

0

Two methods. You can either monitor the message pump for WM_DESTROY and close down on that, or you can set a timer and monitor to see if you have a visible window any more. Note that when the control panel replaces you (closes itself, or user chooses a new screen saver), your window is hidden, and I believe destroyed. Since you are Screen Saver, it seems less risky to possibly abort early than to hang on forever.

So set a non-Form Timer (Form timers may get destroyed if your window is being destroyed), and check yourself periodically. You can also, as somebody points out in the comments to your question, monitor GetParent, to see if it changes.

Cardinal Fang
  • 283
  • 2
  • 12