In a .NET Compact Framework application we are using ocx media player component written by coppercoins.
The media player launches on a new screen when ever user clicks a button. The media player works well on the first time. When we close the media player form and launch it once again on click of the button, it breaks with the following exception
ExceptionCode: 0xc0000005
ExceptionAddress: <address location>
Can someone tell me how to resolve this issue?
Note: we are disposing the media player form as well as the media player activeX wrapper control when the form is closed. The media player is disposed inside the designer code( using as shown below
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
if (disposing)
{
_axPlayer.Dispose();
_axPlayer = null;
}
base.Dispose(disposing);
}
That probably isn't going to be something you'll be able to fix your side and is an issue for forward to the component designer.
As a work around I would suggest retaining the object reference for the duration of the application and not disposing it. Obviously this blows if it occupies a lot of memory.
this solution helped me to fix the issue Media Player Control for .NET Compact Framework
Related
Windows 7 has an AWESOME new feature that applications can report the progress of the current activity through the status bar. For example, when copying file(s) using Windows Explorer, a progress bar is layered on top of the application icon in the task bar and the progress is shown as it updates.
What is the API for exposing the progress bar? Is there MSDN documentation on it?
For below .NET 4, or WinForms in any .NET version
Using the Windows API Code Pack from Microsoft (as Keeron mentioned), it's really simple. You just need to use the TaskbarManager. E.g.
To start the progress:
TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.Normal);
To update the progress:
TaskbarManager.Instance.SetProgressValue(currentValue, maxProgressValue);
And when when you're done, to end the progress:
TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.NoProgress);
There is more you can do, but that should get you started and might be all you need.
For .NET 4 and above with WPF
You can use System.Windows.Shell.TaskbarItemInfo. E.g. in the Xaml for your main window, you'll need to add:
<Window.TaskbarItemInfo>
<TaskbarItemInfo x:Name="taskBarItemInfo" />
</Window.TaskbarItemInfo>
Then to update the progress, you would do something like:
taskBarItemInfo.ProgressState = TaskbarItemProgressState.Normal;
for (int i = 0; i < 100; i++)
{
taskBarItemInfo.ProgressValue = i / 100.0;
Thread.Sleep(50); // whatever the 'work' really is
}
taskBarItemInfo.ProgressState = TaskbarItemProgressState.None;
Don't forget that if you're doing the 'work' on a background thread (which is probably a good idea for long running tasks), you will need to switch back to the UI thread to update the taskbar.
There's a good article in MSDN magazine about the new taskbar APIs. And yes, the feature is awesome :-)
Essentially, it's all about implementing IFileOperation. There's a good article about using it in managed code here.
If you plan to use other Windows 7 Taskbar features, another approach would be to use the library from Microsoft: Windows API Code Pack for .NET Framework which is no longer available at the old link, but can be found on nuget.
I've written an article about implementing the Windows 7 Taskbar progress API in C# (see: Windows 7 Taskbar Progress Bar with C# and .NET). The control is open source (BSD) and has example projects for C# and VB.NET.
This way you don't have to convert the C++ code from scratch.
Actually I use Telerik's RadWindow which you cannot just use <telerik:RadWindow.TaskbarItemInfo>. So I use this workaround for net6.0-windows WPF:
In code behind file I made a property:
public Lazy<TaskbarItemInfo> TaskbarItemInfo { get; set; } = new Lazy<TaskbarItemInfo>(() =>
{
return System.Windows.Application.Current.MainWindow.TaskbarItemInfo = new TaskbarItemInfo();
});
In method part of BackgroundWorker
private void WorkerProgressChanged(object sender, ProgressChangedEventArgs e)
I set the value of the progress:
TaskbarItemInfo.Value.ProgressState = TaskbarItemProgressState.Normal;
TaskbarItemInfo.Value.ProgressValue = (double)progressUserState.ProgressInPercent / 100;
In
private void WorkerRunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
I reset the state:
TaskbarItemInfo.Value.ProgressValue = 0;
TaskbarItemInfo.Value.ProgressState = TaskbarItemProgressState.None;
I have random crashes in my WinJS application when navigating between pages.
The problem is that these crashes never occurs when the app is attached to the Visual Studio debugger; so I can't find where they come from.
I use the WinJS.Application.onerror event to prevent crashes, and log what happens, but as this works well when I try with a random exception, my "uncatchable" crashes doesn't seem to fire this event (I don't have anything logged).
Do you have any idea of what could cause these crashes, or any solution to find more informations ?
Sometimes errors can't fire the WinJS.Application.onerror for several reasons (in my app, the problem was in an iframe, in a page not using winjs).
When it happens, errors can be found in the event log, under "administrative events"
Found this on this link :
http://www.davepaquette.com/archive/2012/09/15/windows-8-store-app-crash-logs.aspx
Jason gives a good solution to this problem in this video (start at time 14:48). In his example, the app was crashing if you had a callback and navigated to a different page before the callback completed. Could this be the case for your app? Any more details on what is going on when you navigate?
For others (since it seems you already know about this!):
To be able to debug easier, use the WinJS.Application.OnError event. Wire up an event handler that dumps out information about the problem before the app crashes.
WinJS.Application.onerror = function (info) {
var err = {
errorMessage: info.detail.errorMessage,
errorUrl: info.detail.errorUrl,
errorLine: info.detail.errorLine,
errorCharacter: info.detail.errorCharacter,
};
Windows.Storage.ApplicationData.current.localFolder
.createFileAsync("crash.txt", Windows.Storage.CreationCollisionOption.openIfExists)
.then(function (file) {
Windows.Storage.FileIO.appendLinesAsync(file, [JSON.stringify(err)]);
});
};
The final stop for exceptions in JavaScript is actually window.onerror; not every exception will get thrown through WinJS.Application.onerror. Try hooking window.onerror directly.
I am currently writing a simple snake clone game for Windows 8 using MonoGame. I am using the XAML - MonoGame template and trying to include advertising support. I have found an issue, pretty sure it's with the AdControl itself, not MonoGame, however it is stealing keyboard focus every time an ad is loaded.
I have tried to reinitialize the MonoGame 'MetroGameWindow' instance to try and get focus back with no luck. Eg,
void GamePage_LostFocus(object sender, RoutedEventArgs e)
{
MetroGameWindow.Instance.Initialize(Window.Current.CoreWindow,this)
// 'this' is 'GamePage' which inherits from 'SwapChainBackgroundPanel'
}
Does any one know any workarounds for this problem? Any help would be appreciated.
This ia a known problem with AdControl. As of now best solution is to set IsEnabled property of AdControl to false. Doing so will prevent AdControl from taking focus on ad reloads while remaining clickable. See following discussion on bing ads forum: http://community.bingads.microsoft.com/ads/en/publisher/f/63/t/73548.aspx
I'm writing a small audio recorder component in Silverlight 4. It works fine, but I've noticed that when I'm recording audio, the light on my webcam turns on indicating that the camera is active.
While I know that I'm not doing anything insidious with the webcam, my users would have every right to be suspicious. Is it possible to tell Silverlight that I'm only interested in microphone access and not activate the webcam?
FWIW here's how I'm accessing the mic:
private CaptureSource _source = new CaptureSource();
private MemoryAudioSink _sink; // Inherits from AudioSink. Doesn't do much more
// than store PCM audio stream in memory
private void Record_Click(object sender, RoutedEventArgs e)
{
if (( CaptureDeviceConfiguration.AllowedDeviceAccess ||
CaptureDeviceConfiguration.RequestDeviceAccess() ) &&
_source.State == CaptureState.Stopped)
{
_sink = new MemoryAudioSink();
_sink.CaptureSource = _source;
_source.Start();
}
}
CaptureSource will frequently grab the default video input device, even if you don't tell it to. Though you aren't using the camera, Silverlight is indeed accessing it. Hopefully, MS will fix this odd behavior in a later version of Silverlight.
In the meantime, just explicitly set VideoCaptureDevice to null:
var _audioCaptureSource = new CaptureSource {VideoCaptureDevice = null};
This would depend on the webcam driver - Silverlight would have no control over this.
I'm guessing its related to your use of CaptureSource. Microsoft's web site claims that:
Silverlight 4 APIs only use
CaptureSource in a video scenario
where audio may not be relevant.
Is there a way to get audio without creating your own CaptureSource?
I would like to be able to gather info like how often certain windows are opened, what types of user data are accessed, how often menu items are clicked, etc. Does anyone know of a 3rd party (open source or commercial) Cocoa/Obj-C library or plugin that would allow me to gather this info?
I have used pinch media in the past, and they merged with Flurry. Library was simple to use and was setup in around 40 minutes.
I don't know any library for that but at least to get informed about when the user switches the front application you can install an event handler like this:
EventTypeSpec eventType;
eventType.eventClass = kEventClassApplication;
eventType.eventKind = kEventAppFrontSwitched;
EventHandlerUPP handlerUPP = NewEventHandlerUPP(FrontAppSwitchedDetector_callback);
OSStatus status=InstallApplicationEventHandler(handlerUPP,1,&eventType,self,&_eventHandlerRef);
... and when receiving an callback you may get the current front application process:
pascal OSStatus FrontAppSwitchedDetector_callback(EventHandlerCallRef nextHandler,EventRef theEvent,void* userData)
{
ProcessSerialNumber newSerial;
GetFrontProcess(&newSerial);
//to something with that ....
return (CallNextEventHandler(nextHandler, theEvent));
}