I'm currently developing an application for Windows platform that will be able to play Quick Time videos.
The targeted OS versions are Windows XP, Windows Vista and Windows 7.
I successfully used the Apple ActiveX QuickTime Control 2.0 (in C#) and everything works well on Windows XP.
However, on Vista and Windows 7 I'm facing problems with properly disposing the control.
Here are the "steps to reproduce" :
- I create the Quick Time control dynamically at runtime and I place it on a panel;
I successfully play videos with it;
At some point I close the application main form; the application windows is destroyed and the application will continue to run in the background (doing operations like syncing videos); at this point the control is disposed using IDisposable pattern; I can't explicitly dispose the Movie object (from the ActiveX control) because I get an exception like: "COM object that has been separated from its underlying RCW cannot be used."; I just use (AxQTOControlLib.AxQTControl) player.Dispose(); On Windows XP this is fine but not on Vista and 7
I restore my application (from tool bar where it was running in background) and try to open the video again; At this point an AccessViolationException "Attempted to read/write protected memory" is thrown;
My questions are:
Why is this happening only on Vista and Windows 7 ?
On XP is a hidden leak ?
What is the recommended way to dispose the control (with its movie object) when it is created at runtime ?
I'm now using an explicit Movie.Disconnect() call (although I don't now what this disconnect means because I could not find proper documentation) fallowed by a QuickTimeTerminate() call before the form is closed.
While my method is working it is kind of design breaking so I would like to know a better way of doing this.
Thank you,
Mosu'
Update:
I just discovered that my method is not workink. I use to players: QuickTime control and Windows Media player control (both ActiveX) and when one fails to play a file the other one is used. I was seeing the output of WindowsMedia player and thinking the methos IS working.
So my fix is not working at all.
Lots of people seem to be having this error.
This page offers an interesting approach: http://www.theusenetarchive.com/usenet-message-how-to-properly-destroy-quicktime-activex-object-10384503.htm
The crash occurs because of file handles still being open. I was
'unloading' movies from the Quicktime control by wiring a null string
to the FileName or URL property. Quicktime doesn't handle this
correctly and leaves the original file open. So instead I wired
a path to an actual image file (Quicktime does images too) that was
all black. Eveything seems fine now.
Related
I am working on a program that starts several other c# WPF applications and checks wether there are errors (using .NET Automation Services / UITesting).
One of the requirements of it is to take a screenshot of the main window and to put it into a word document. I alread got it working quite fine when it´s one application at a time (using code from this site: http://www.developerfusion.com/code/4630/capture-a-screen-shot/) , but as soon as i am using parallelism (say, checking 5 applications in a parallel manner), i am running into the problem that the screenshots of the windows may be overlapped by other windows that just popped up or that are always brought to the front (e.g. splash screens). Bringing the window to the front does not really help.
There was an older similar thread not directly regarding to WPF applications, and sadly, without a clear solution: Taking screenshot of a partially hidden window in a programmatic way
Is there a way to get a "clean" screenshot, may be with the use of the windows AutomationElement instance?
I have a winform within a remote desktop application that is built dynamically with a container panel for a toolbar with large (regular) buttons. The application is writen in C# and .NET 4.0. The application is viewed as it should only if I do not maximize the window (meaning restored view is fine).
Now, after RDP login - within most client computers - the application looks fine (even when we maximize and restoring). Within low resolution client computers (800x600), the buttons on the toolbar are not displayed in the right position (such as in the 1024x768 clients).
I used double buffering and it didn't help... the problem may or may not be depended on the screen resolution (it can be memory issue or something). It is not a problem of localization layout.
The following image shows the Fine and Bad states: http://imgur.com/gO4UJ,v7O9K
What can I do to resolve this issue?
OK, so in case anybody gets to this kind of case, this is the thing that made the issue:
In the form, there was an empty repaint override. The programmer that created the form was overriding the repaint with an empty method (don't know why, I guess I'll ask my team for the business logic).
How did I reproduce it in the development environment? Following Albin Sunnanbo's note, I ran the RDP application in minimized version during initialization, and I noticed that it occurs with large resolution clients also in this use case... So, I know repaint occurs while performing a window resize - and this made me suspicious about the method...
==> On a side note, I guess this is why inheritance is so bad, and going on to WPF is better. It took me 3 days to understand why this issue occurred.
I'm working on a .NET 4 WPF application, and just the other day, came across a very peculiar bug. I have three Windows 7 Pro machines involved: laptop (1366x768), desktop (1680x1050, multi-monitor), and the remote machine (resolution unknown). Our application is installed on the remote machine.
Consider the following events: I remote desktop into the remote machine from my laptop, start our application, and launch a particular feature (an mdi child) within the application. If I connect to the same remote session from my desktop (thus closing the session on my laptop), this feature within my application becomes completely unusable. By unusable, I mean combo box drop downs are showing in the top/left corner (much like what's described here), other controls aren't laid out correctly, and some controls don't even show at all. Mouse coordinates appear to be off in that clicking certain controls no longer invokes the appropriate actions. It's the strangest thing I've ever seen.
If I close the application and launch a new instance on my desktop, things work great. Also, it only seems to happen when I launch the feature on my laptop, then move to the desktop. Never the other way around.
I wish I could show some code, but I don't really even know where to start or what to show. I can say that it only happens on certain features. Some features handle the resolution change perfectly.
Has anyone else seen these types of symptoms? Or know what could cause them or how they could be fixed?
This is a little embarrassing. After a few hours of "process of elimination", I found that another developer had added some unmanaged code to automatically maximize the window. The approach they followed is documented here. This approach does not work through remote desktop sessions. Lol.
When exiting my .NET CF 3.5 application on the Motorola MC3100 (CE 6.0 version only) I get the error message "Application xxx has encountered a serious error and needs to shut down". I then need to warm boot the device for the application to work again.
This code works fine until the application is shutdown and it only fails if a font is set on a control in the application. Everything also works fine on .NET CF 2.0 and all of the other Motorola, Intermec, Psion, HHC devices I have tried with .NET CF 3.5.
Here is my current test code:
[MTAThread]
static void Main()
{
Control oCtrl = new Control();
oCtrl.Font = new System.Drawing.Font("Tahoma", 10F, System.Drawing.FontStyle.Bold);
// Setting the controls font to null works
// oCtrl.Font = null; Works
// Setting the Control to null does not work, still get error
// oCtrl = null; Doesn't work
// Setting a font, not on a control, also works fine.
// System.Drawing.Font font = new System.Drawing.Font("Tahoma", 10F, System.Drawing.FontStyle.Bold);
}
I have seen a few links that seem related:
Application crashes on exit when using Button2
Problem with CF 3.5 and Windows CE 6
Error on close
But so far the only recommendation I have found is to eliminate fonts in the application. In this case there is just too many places where fonts are set, including linked assemblies, that it would be impossible.
Has anyone else seen anything like this. It seems like something to do with the controls not properly disposing of the fonts on these versions.
I faced exactly the same problem.
Tried the following (none solved the issue):
Remove all the new Font() statements
Use Form.Close() instead of Application.Exit()
Move the whole application to .NET CF 3.5
Attempt to remove SQLite dependencies
The only solution that finally worked for our case, (however it is not a "pretty" solution), has been the following command in the MainForm.Closed()
Process.GetCurrentProcess().Kill()
I've had this exact issue with the MC3190. The solution I found was to keep track of all forms that were opened in the application by adding each instance to a global List and upon application exit loop through the list and call a Form.Dispose on each item in the list. Has stressed me out for months.
I encountered the same problem : Motorola MC3100, with wince6, only crashing at application exit when running standalone, and no crash when running with VS debugger attached. when crashed, the OS was HS and the only solution was to coldBoot the device.
And i manage to deal with it with the following solution.
My app was using Application.exit() in a modal sub form, and it seems it doesn't deal well with some unmanaged ressources used by font.
in my case the precise cause was to use new Font(...) in my main form. using it in modal subform didn't cause any issue.
Bringing back the application.exit() in the main form didn't work either, nor disposing explicitly font ressources (i made a lot of try oriented this way).
At the end the only solution i find that works was to quit the application by closing the mainform instead of using application.exit(), and it works well.
Application.Exit() is not recommended way to close applications. Close all opened forms in order to close application.
http://blogs.msdn.com/b/tom_krueger/archive/2005/02/24/379678.aspx
We experienced this issue with Motorola MC3190 devices running Windows CE 6.0 / .NET 3.5 CF. For months we were encountering an intermittent fatal error dialog upon closing our application. Every possible option was explored from ThreadAbort exceptions to making sure every single resource was properly disposed.
Normally, if a device doesn't have a particular font or is trying to access one that happens to be unrecognized, it will default to Arial. With the MC3190 however, if a font isn't recognized, the device will display a fatal error dialog and freeze after exiting an application. This results in the user having to warm boot (sometimes cold boot).
We came up with two solutions to this problem:
Set the application-wide font to something that is supported (replace Tahoma with Arial)
Reset any global Font objects either by instantiating with a supported font OR setting to null.
You should make a Form and run your code in Application.Run() context. At the end of Run, many resources are disposed "by magic". Otherwise you must dispose every resources that need to be disposed.
We encountered the same problem and solved with this line of code in the MainForm.Closed()
Process.GetCurrentProcess().Kill()
I had the same problem on a Motorola 9190-G using the .NET Compact Framework 3.5. At times I would have to warm boot the device because it would freeze after closing my application.
I was able to workaround the issue by specifying the font of the form the ListView was contained in in the Constructor to be Arial, 10pt, Regular. I then programmatically set the font to my desired font. For example, myListView.Font = new System.Drawing.Font("Tahoma", 11F, System.Drawing.FontStyle.Bold);.
If I had the font set to any other font/font style/size combination, I would receive the "program encountered a serious problem and must shutdown" error message when closing the application on the mobile device.
The problems with Windows Media Player on a .NET CF based application are endless. In one of the .NET CF 3.5 applications, we are using ActiveX controls to play videos. The code for the media player ActiveX control is from this MSDN article. It had few memory leak problems, but the bugs are sorted out with the help of this article.
The new problem - when we terminate the application, it closes the user interface but the process is running in the background. This is seen in Task Manager's Processes tab. This hanging process is making the system totally unstable. After playing a video for few yours, the entire system hangs and forces to reboot.
Please help me to understand why the process is hanging in background after closing and what fix in the code terminates the process completely.
First, are you sure you are terminating your app in code (and that this code is executing), or is the user clicking the X on the upper-right (for the touch screen devices). I ask because the X doesn't close an app by default - it only minimizes it (unless you take action to do more yourself, etc.).
Assuming that isn't the problem, it's hard to answer based on this limited info, but my guess would be that there's an ActiveX object that wasn't properly Release'ed. The object in question may be your own app, if you pass a reference to your app to the ActiveX control you are using (and if you don't tell the other control to release you). So I'd suggest going through your code and taking inventory of all COM objects, where they are created, where they are AddRef'ed, etc., and make sure you are Releasing and/or setting them to null (perhaps with additional proper cleanup of the objects themselves, such as first telling them to stop playing anything, etc.).
P.S. Your post was a bit ambiguous as to whether the problem is that the app doesn't exit when it should, or if it is causing the device to hang after intentionally running for a while...