.NET Powerpoint presentation stopping after 4 hours? - c#

I wrote a command line application in C#.NET that programmatically edits an existing powerpoint, and then starts the slideshow. The powerpoint is automatically configured to advance slides. The problem I am running into is that powerpoint will quit after 4 hours. Any ideas?

I think the computer is going to sleep or my other guess is that the program is causing a memory leak causing the program to crash out and close.

If the computer's gone to sleep or the screensaver has kicked in, waking it back up should put you back inside a running slide show.
If the slide show has actually stopped, I think you can rule out a sleeping computer/screensaver problem. In that case, it might be a problem with your program or it might be that PPT just craps out after some amount of time running a slide show. In some versions on some computers (nobody's ever been able to pin down the magic combo that triggers this).
To rule that out, start the presentation independent of your app and see if it runs w/o problems.

Like everybody already mentioned. Maybe the screensaver or when the Presentation is over, it closes. Maybe you could write your program in such way, that when it is on the last slide, to start again from the 1st one, which will actually create an infinite loop. If your goal is to only show the slide show.

Related

Excel interop automation periodically freezes for 40-60 seconds

My program uses C# and interop to create complex Excel documents. The generation process runs against an invisible background instance of Excel. One particular interop call sometimes runs incredibly slowly. Most individual interop commands take just a few milliseconds, but assigning to the Font.Bold property can sometimes take 40-60s.
The 'slow' runs of this line of code are intermittent but follow a pattern. After a slow run, all successive runs will be fast for about 7-10 minutes, after which the next call will be slow. It is like there is a 'timer' which is reset on each slow run. While the timer is counting down all interop runs smoothly. Once the timer has expired, the next assignment to Font.Bold will be slow. It will be slow no matter whether the call comes immediately after the timer has expired, or if I leave the computer idle for a couple of hours and run the code again.
Restarting my program has no impact on this invisible timer. In other words I can run my code, wait for a slow run, and then exit the process. Then if I immediately start my code again, I will get fast runs for the next 7-10 minutes. I have ensured there are no instances of Excel or other Office apps running, including hidden ones lingering in the background. The only thing which 'resets' the timer is restarting my machine. It is like the timer exists on a system level outside of Excel or my code.
This applies in Debug and Release solution configurations, running with and without the debugger attached.
There is one other crucial piece of evidence. If I manually open an instance of Excel from the Start menu (i.e. driving it using mouse and keyboard rather than interop), there are repro steps for what looks like the same problem.
Create blank workbook
In the Home ribbon click Cell Styles
Right-click a style and click Modify...
Click the Format... button
Excel completely freezes for 40-60 seconds, then finally the dialog opens and behaves as normal
The freeze in the final step follows the same 7-10 minute cooldown behaviour as when I assign to the Font.Bold property in interop. The invisible 'timer' in the background is apparently shared between the Excel dialog and the interop code. In other words a slow run in interop will be followed by 7-10 minutes of Excel not freezing. And a frozen dialog in Excel is followed by 7-10 minutes of fast interop.
I have phrased this question as one about interop since that is how I first came across the problem. It may in fact just be a general Excel problem or bug, but it was only after many fruitless days of debugging my code, trying desperate garbage collection/Marshal.ReleaseComObject nonsense etc. that I discovered the Excel GUI symptom.
What is causing this slowness and what can I do about it?
Windows version: Windows 10 Home 21H1 (19043.2006)
Excel version: version 2209 Build 16.0.15629.20152 64-bit
I have a partial answer or at least explanation to my own question.
My deduction is, Excel hangs while trying to contact an offline printer. Work around the problem by setting the Windows default printer to one which is available.
The key was finding a post (archive 1, 2) where someone describes the Excel freezing dialog symptom, and suggests changing the system default printer. My Windows default printer was set to a network-attached HP LaserJet which Windows Printers & scanners says is Online even though it's not been connected to the network or powered on in months. Changing the default printer to Microsoft Print to PDF eliminated the hangs both from interop and the live usage of Excel GUI.
This is speculation, but I imagine when the freeze happens Excel is trying to contact the printer, perhaps to determine which device fonts it supports. The Excel GUI thread (!) is ultimately blocked on a network call which times out. The 40-60 seconds is presumably the network timeout on trying to reach the printer, and the 7-10 minute 'timer' is an actual OS-wide timer which says 'if connection to a network printer fails assume it is unreachable and don't try to contact it again in this interval'.
I've tried on another machine with a different offline default printer, but I could not reproduce. Presumably the problem is only with specific printer drivers.
I'm not sure what can be done to prevent this problem in the wild when the code is running on other systems. Hopefully the problematic configuration is rare. I feel the blame could equally lie with Excel, a printer driver, or the Windows OS, so a bug fix seems unlikely.

Is there a way to prevent PDFCreator from remembering and resuming killed jobs?

I'm writing a C# program that is supposed to serve as an intermediate step inside a PDFCreator workflow, while a document is being printed.
It's a regular console program and it works fine when everything else is fine. The root problem, as I've discovered, is that there is currently (i.e. in PDFCreator v4.1.3) no way to cancel the print job from inside my program, should the need arise. PDFCreator simply doesn't check the exit code and continues onto the next step regardless of what happened in my program.
Having exhausted the obvious options I've naturally resorted to the only way I could think of: killing the parent process from inside my app. This works, sort of. It cancels the immediate printing process.
But the problem starts again when I try to print another document. As it turns out, PDFCreator remembers the pending printing task as soon as the workflow starts. If it is killed before finishing, it stays in its queue and is retried the next time. This means the the tasks accumulate when I kill them!
I haven't had any success trying to determine where exactly the PDFCreator stores these pending tasks, so I can't delete them. And so I'm stuck.
I've raised the issue on the PDFCreator forum, but the community there seems to be rather slow to respond.

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

Application non responsive

Hi Guys I have a winform which acts as an interface for a database. At some point the user will select a directory which contains 30 to 40 files. These files will have to be inserted into the database as raw data. That is as is. Then that raw data will interrupted and fixed up. Once this is done the user can dump the fixed data to one excel file. This works perfectly when I am running it in visual studios in release or debug mode. However when I try to run it form outside of visual studios (that is from the bin / release file) it stalls then becomes non-responsive. I and the user don't mind if it becomes slow (about 60 thousand records are printed). However why does it stop working. I figured the part where it stops responding and it doesn't seem like its deadlocked? Any ideas of how to improve it would be appreciated. I also requested that my application runs with high priority but that still doesn't help.
You need to do all that processing in a separate thread. I would recommend using the BackgroundWorker.
Here is information about the class - http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
Here is an example of how to use it - http://fernandof.wordpress.com/2007/04/04/implementing-multi-threading-in-winforms-using-the-backgroundworker-class/

PowerPoint SlideShowSettings.Run() does not run embedded video

I have a C# application that runs on a computer connected to a large display in our cafeteria. The application pulls all the PowerPoint files out of a folder and runs each one as a slide show continuously. Everything was working fine until someone decided to insert a movie clip onto a slide. The problem is that the movie never starts. If open the presentation in PowerPoint and run the show it works, and if I right click on the presentation and click 'show' it works. Here is the code I am using to open the presentation and start the slideshow.
pres = app.Presentations.Open(pptPath, MsoTriState.msoTrue, MsoTriState.msoTrue, MMsoTriState.msoFals);
pres.SlideShowSettings.Run();
Is there something else I need to set to get the Run() method to also start movies?
Edit: The presentation in question only had one slide in it which contained the movie. If I added another slide to it, it worked fine. Also tried adding a slide before and had the same problem, so apparently the problem only exists for the last slide in the presentation.
The main issue here is that PowerPoint animations (video, audio, custom motion paths, etc.) will only play when the SlideShowWindow has the focus. What this means is that when you're running your app and launching PPT, your app still maintains the focus and hence animations don't run (that doesn't stop you from manually manipulating your running deck though).
There are a couple of ways around this:
You can call the API SetWindow to
bring your SlideShowWindow to the
front. Not a great way to do it in
my opinion.
The very easiest way is just to save
your .ppt/.pptx to a .pps/.ppsx
(PowerPoint Show). With that, you
can use your same code to run it and
it will launch and take the focus
automatically (and your animations [video, et al) will run as you've intended).
Found the problem. I had a thread.sleep statement in the presentation's app_SlideShowNextSlide event handler that handled the end of one slideshow and starting the next. I wasn't thinking at the time and this code was running in the same thread at the slideshow itself. I created a timer object instead and moved the necessary code into the timer's elapsed event handler.

Categories

Resources