I have a C++ application in which I'm trying to show a WPF form (named WSWindow), specifically one that inherits from the System.Windows.Window class so that I can get the window handle using the WindowInteropHelper class.
My problem is that whenever I make the call to the method below, the application crashes.
public IntPtr GetHWND()
{
if (ivWindow == null)
{
ivWindow = new WSWindow();
ivWindow.WindowStartupLocation = WindowStartupLocation.Manual;
ivWindow.Show();
}
IntPtr handle = new WindowInteropHelper(ivWindow).Handle;
return handle;
}
I believe the WSWindow constructor is causing the crash. On the C# side of things there's a WSService class that calls the WSWindow constructor, and if I put the WSWindow constructor in the WSService constructor, the C++ app crashes on calling the WSService constructor (something that works fine when the WSService constructor does not contain the WSWindow constructor). Also, in addition to calling the above method, I've tried the following in the C++ app:
WSWindow^ w = gcnew WSWindow();
and there are log lines immediately after this line that don't get written to the log file.
In the WSWindow contructor, there's a call to InitializeComponents, which is generated code in the WSWindow.g.cs file:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public void InitializeComponent() {
if (_contentLoaded) {
return;
}
_contentLoaded = true;
System.Uri resourceLocater = new System.Uri("/Project_Name;component/wswindow.xaml", System.UriKind.Relative);
#line 1 "..\..\WSWindow.xaml"
System.Windows.Application.LoadComponent(this, resourceLocater);
#line default
#line hidden
}
At first I thought maybe the call to LoadComponent was failing because the uri couldn't be resolved, but I added a log line in the WSWindow constructor before the call to InitializeComponent() which gets written when the WSWindow is created from a Windows Forms test app, but not when the WSWindow is created by a call from the C++ app, so it seems like nothing in the WSWindow constructor even gets executed, it just crashes right away.
There's no problem with references that I can tell; I've written a couple test methods, one that returns an int, one a simple custom Window object with width/height members and successfully called both from the C++ app.
I've also successfully retrieved the handle to the WSWindow when it is compiled as a WPF app and run before launching the C++ app, but I need to be able to create the WSWindow from a call within the C++ app.
I've spent days on this problem trying to figure out why the crash is occurring with no luck. I'm hoping someone that reads this knows something about WPF that could be causing this issue, or a known issue between C++/CLI and WPF controls. I'm totally out of ideas.
Additional info: When I start the C++ app and attach VS to the process, nothing shows up in the call stack (a separate problem for me to work on), but I noticed a couple exceptions that look like they might be related:
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b158..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b608..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
The solution was that I needed to mark the thread making the call to create/show the WPF Window with the [STAThread] attribute.
Related
There's no error message and no indication why it is not displaying the window. The app initialises App.xaml.cs: App() {} and I can step through the App.xaml file. It gets the startup uri and then... silence. No output in the Output window and no unhandled exception and no window, I can't find where to put a breakpoint to debug as it isn't hitting the start of MainWindow.xaml.cs.
Really confused.
This was working 20m ago.
In that time all I did was add Windows.Office.Interop.Outlook reference. I removed the reference and rebuilt but still the same. Would that cause this problem? Has anyone seen this before? Google isn't helping!
EDIT :
App.xaml.cs:
public App()
{
using (var dbContext = new DBEntities())
{
if (!db.Exists())
{
try
{
db.Database.Create();
MessageBox.Show("Database created"); // this is the problem!!
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
}
}
I've added App.xaml.cs, I found that the problem was using a MessageBox to give info (this is still in development!). I'd been meaning to get rid of it and eventually did and my problem went away. This meant I could find relevent Goolge results:
MSDN query and answer for exactly my problem
I will be adding an 'loading window' in between app load and main window load eventually in which I will be able to feedback information using Bindings etc.
Fixed error by removing the MessageBox.Show(..) call. The selected answer from the MSDN URL given in the question states:
"I performed a test based on your description, the applicationi stop at the method : USER32!GetMessageW+0x33, calling USER32!NtUserGetMessage"
I assume this is what was occurring in my case, although I didn't test it.
What happens if you create a new window and set that as the StartupUri?
You also might want to create a new project and make sure that the namespaces referenced in the App.xaml in your existing app haven't somehow been inadvertently edited.
I want to circunscribe this question to the specific context of WPF aplications.
The accepted answer says
"You should only to catch exceptions that you can actually do something about"
and also
"Note that if you're simply trying to catch any unhandled exceptions that might occur for the purposes of logging or error reporting, you should be using the AppDomain.UnhandledException event"
Well, all would be good and well EXCEPT (pun intended) that I had a very serious problem while deploying a WPF application which would crash right at application startup, with the dreaded IOException error in PresentationFramework.
I tried the Application.Current.DispatcherUnhandledException, but the crash apparently happended outside its grasp. I tried Windbg but the error messages were still elusive.
Then I followed advice from this post (changing app.xaml Build Action property from "Application Definition" to "Page" and putting Main() function inside App.xaml.cs itself), putting a try/catch with a MessageBox (it could be a logging call, whatever), and the message displayed immediately led me to the solution.
So the question is:
Considering WPF has its own esoterical bugs, is there any actual problem in putting Main() function body inside a try/catch?
Here is my current code:
public partial class App : System.Windows.Application {
/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public static void Main() {
try {
var v3d = new App();
v3d.InitializeComponent();
var shellview = new ShellView();
v3d.Run(shellview);
} catch (Exception e) {
MessageBox.Show(e.ToString());
}
}
And for the record, I was getting "Cannot locate resource 'app.xaml'" caused by some culture mismatch, the problem happened in only one of two similar machines apparently because one OS (Win7) is English and other is Portuguese. I solved it with this answer.
I'm working with a Silverlight 4 application and we use Prism/MEF to build modules.
Each module is created as a Silverlight application. We then use a ModulesCatalog.xaml file to control how the modules are loaded.
We had 6 modules and everything was working perfect.
This week we're adding a 7th module and we just have the new Silverlight application created. We setup the module class as follows.
[ModuleExport(typeof(InsightModule))]
public class InsightModule : IModule
{
}
Then we added an entry to our ModulesCatalog file.
Now when we run the application we start getting all types of recomposition errors. The stack shows this.
at System.ComponentModel.Composition.CompositionResult.ThrowOnErrors(AtomicComposition atomicComposition)
at System.ComponentModel.Composition.Hosting.ExportProvider.OnExportsChanging(ExportsChangeEventArgs e)
at System.ComponentModel.Composition.Hosting.CatalogExportProvider.OnCatalogChanging(Object sender, ComposablePartCatalogChangeEventArgs e)
at System.ComponentModel.Composition.Hosting.ComposablePartCatalogCollection.OnChanging(Object sender, ComposablePartCatalogChangeEventArgs e)
at System.ComponentModel.Composition.Hosting.AggregateCatalog.OnChanging(ComposablePartCatalogChangeEventArgs e)
at System.ComponentModel.Composition.Hosting.ComposablePartCatalogCollection.RaiseChangingEvent(Lazy`1 addedDefinitions, Lazy`1 removedDefinitions, AtomicComposition atomicComposition)
at System.ComponentModel.Composition.Hosting.ComposablePartCatalogCollection.Add(ComposablePartCatalog item)
at Microsoft.Practices.Prism.MefExtensions.Modularity.MefModuleInitializer.CreateModule(ModuleInfo moduleInfo)
at Microsoft.Practices.Prism.Modularity.ModuleInitializer.Initialize(ModuleInfo moduleInfo)
Then you get the standard output.
The exception message was: The composition remains unchanged. The changes were rejected because of the following error(s): The composition produced multiple composition errors, with 57 root causes. The root causes are provided below. Review the CompositionException.Errors property for more detailed information.
1) Change in exports prevented by non-recomposable import 'EyeCue.Common.AboutEyeCueView.ViewModel (ContractName="EyeCue.Common.AboutEyeCueVM")' on part 'EyeCue.Common.AboutEyeCueView'.
WHat's puzzling is why none of the other 6 modules caused this problem but now all of a sudden, this new module without anything going on in it is causing a recomposition of the catalogue. It makes no sense.
Plus I have ctor's that import in some cases and that's they what I had to do to get things to work, so this is not as simple as going to setting the Allow Recomposition attribut.
I've downloaded the VisualMFX but this line of code throws an Object Not initialized exception.
this.compositionInfo = new CompositionInfo(_aggregateCatalog, _container);
Both _aggregateCatalog & _container are not null when this happens.
In summary, why would a 7th module all of a sudden start causing recomposition? Especially when the module isn't even defining any exports or imports at this time? That leads to how do we stop it to address this problem?
The issue turned out to be a reference to an assembly which had Copy Local set to true.
Making sure all references which are also set in the main application assembly were set to Copy Local = false seems to resolved the problem.
I've encountered a problem with the XBAP Script Interop feature that was added in WPF 4. It involves a combination of the following:
Accessing members of a script object from .NET
Running .NET code in a callback invoked from JavaScript
Running in Partial trust
This seems to be a "pick any two" scenario... If I try and do all three of those things, I get a SecurityException.
For example, combining 1 and 3 is easy. I can put this into my hosting web page's script:
function ReturnSomething()
{
return { Foo: "Hello", Bar: 42 };
}
And then in, say, a button click handler in my WPF code behind, I can do this:
dynamic script = BrowserInteropHelper.HostScript;
if (script != null)
{
dynamic result = script.ReturnSomething();
string foo = result.Foo;
int bar = result.Bar;
// go on to do something useful with foo and bar...
}
That works fine, even in a partial trust deployment. (I'm using the default ClickOnce security settings offered by the WPF Browser Application template in Visual Studio 2010, which debugs the XBAP as though it were running in the Internet zone.) So far, so good.
I can also combine 2 and 3. To make my .NET method callable from JavaScript, sadly we can't just pass a delegate, we have to do this:
[ComVisible(true)]
public class CallbackClass
{
public string MyMethod(int arg)
{
return "Value: " + arg;
}
}
and then I can declare a JavaScript method that looks like this:
function CallMethod(obj)
{
var result = obj.MyMethod(42);
var myElement = document.getElementById("myElement");
myElement.innerText = "Result: " + result;
}
and now in, say, a WPF button click handler, I can do this:
script.CallMethod(new CallbackClass());
So my WPF code calls (via BrowserInteropHelper.HostScript) my JavaScript CallMethod function, which in turn calls my .NET code back - specifically, it calls the MyMethod method exposed by my CallbackClass. (Or I could mark the callback method as a default method with a [DispId(0)] attribute, which would let me simplify the JavaScript code - the script could treat the argument itself as a method. Either approach yields the same results.)
The MyMethod callback is successfully called. I can see in the debugger that the argument passed from JavaScript (42) is getting through correctly (having been properly coerced to an int). And when my method returns, the string that it returns ends up in my HTML UI thanks to the rest of the CallMethod function.
Great - so we can do 2 and 3.
But what about combining all three? I want to modify my callback class so that it can work with script objects just like the one returned by my first snippet, the ReturnSomething function. We know that it's perfectly possible to work with such objects because that first example succeded. So you'd think I could do this:
[ComVisible(true)]
public class CallbackClass
{
public string MyMethod(dynamic arg)
{
return "Foo: " + arg.Foo + ", Bar: " + arg.Bar;
}
}
and then modify my JavaScript to look like this:
function CallMethod(obj)
{
var result = obj.MyMethod({ Foo: "Hello", Bar: 42 });
var myElement = document.getElementById("myElement");
myElement.innerText = "Result: " + result;
}
and then call the method from my WPF button click handler as before:
script.CallMethod(new CallbackClass());
this successfully calls the JavaScript CallMethod function, which successfully calls back the MyMethod C# method, but when that method attempts to retrieve the arg.Foo property, I get a SecurityException with a message of RequestFailed. Here's the call stack:
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessSecurityEngine.Check(PermissionSet permSet, StackCrawlMark& stackMark)
at System.Security.PermissionSet.Demand()
at System.Dynamic.ComBinder.TryBindGetMember(GetMemberBinder binder, DynamicMetaObject instance, DynamicMetaObject& result, Boolean delayInvocation)
at Microsoft.CSharp.RuntimeBinder.CSharpGetMemberBinder.FallbackGetMember(DynamicMetaObject target, DynamicMetaObject errorSuggestion)
at System.Dynamic.DynamicMetaObject.BindGetMember(GetMemberBinder binder)
at System.Dynamic.GetMemberBinder.Bind(DynamicMetaObject target, DynamicMetaObject[] args)
at System.Dynamic.DynamicMetaObjectBinder.Bind(Object[] args, ReadOnlyCollection`1 parameters, LabelTarget returnLabel)
at System.Runtime.CompilerServices.CallSiteBinder.BindCore[T](CallSite`1 site, Object[] args)
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at XBapDemo.CallbackClass.MyMethod(Object arg)
That's the whole trace as reported by the exception. And above CallbackClass.MyMethod, Visual Studio is showing two lots of [Native to Managed Transition] and an [AppDomain Transition] - so that's the whole of the stack. (Apparently we're on a different thread now. This callback is happening on what the Threads panel describes as a Worker Thread - I can see that the Main Thread is still sat inside my WPF button click handler, waiting for the call to the JavaScript CallMethod function to return.)
Apparently the problem is that the DLR has ended up wrapping the JavaScript object in the ComBinder which demands full trust. But in the earlier case where I called a JavaScript method via HostScript and it returned me an object, the HostScript wrapped it in a System.Windows.Interop.DynamicScriptObject for me.
The DynamicScriptObject class is specific to WPFs XBAP script interop - it's not part of the usual DLR types, and it's defined in PresentationFramework.dll. As far as I can tell, one of the jobs it does is to make it possible to use C#'s dynamic keyword to access JavaScript properties without needing full trust, even though those properties are being accessed through COM interop (which usually requires full trust) under the covers.
As far as I can tell, the problem is that you only get these DynamicScriptObject wrappers for objects that are returned from other DynamicScriptObject instances (such as HostScript). With callbacks, that wrapping doesn't seem to occur. In my callback, I'm getting the sort of dynamic wrapper C# would normally give me in plain old COM interop scenarios, at which point, it demands that I have full trust.
Running it with full trust works fine - that would be the "1 and 2" combination from the list above. But I don't want to have full trust. (I want 1, 2, and 3.) And outside of callback situations, I can access JavaScript object members just fine. It seems inconsistent that I can access a JavaScript object just fine most of the time, but accessing an identical object in a callback is forbidden.
Is there a way around this? Or am I doomed to run my code in full trust if I want to do anything interesting in a callback?
I haven't done XBAP in a while, but I am curious if it is the dynamic type that could be causing the issue. Try changing the dynamic parameter to type object and see if it will work.
[ComVisible(true)]
public class CallbackClass
{
public string MyMethod(object arg)
{
return "Arg is: " + arg.ToString();
}
}
I am developing a Silverlight 3 application and I would like to delegate all unexpected error handling in a single instance of a class I have named ErrorHandler. This class has one method named HandleApplicationException, plus a couple of other methods to handle more specialized errors.
In my application I am using Unity for dependency injection, but since I want the error handling object to be available even when the Unity container is not yet set up, I register the object as AppDomain global data in the App class constructor, this way:
public App()
{
this.Startup += this.Application_Startup;
this.Exit += this.Application_Exit;
this.UnhandledException += this.Application_UnhandledException;
AppDomain.CurrentDomain.SetData("ErrorHandler", new ErrorHandler());
InitializeComponent();
}
And in case of unhandled exception, I retrieve the error handler object and use it this way:
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
e.Handled = true;
var errorHandler = AppDomain.CurrentDomain.GetData("ErrorHandler") as ErrorHandler;
Debug.Assert(errorHandler != null, "No ErrorHandler registered.");
errorHandler.HandleApplicationException(e.ExceptionObject);
}
The problem is that the AppDomain.GetData method in the Application_UnhandledException method is throwing a MethodAccessException. I don't understand why, as I am just invoking a public method on the AppDomain class. I have used a similar approach in other applications and it worked fine (anyway these were not Silverlight applications).
So, what's going on? Am I doing something wrong?
Ok, I got it. From MSDN documentation:
This member has a
SecurityCriticalAttribute attribute,
which restricts it to internal use by
the .NET Framework for Silverlight
class library. Application code that
uses this member throws a
MethodAccessException.
I have resorted to storing the error handler in a public property in the App class, then I access it using ((App)Application.Current).ErrorHandler. I don't like doing things this way but I suppose it is ok in this special case.
Why can't you just use a static instance of ErrorHandler? I.e. have something like ErrorHandler.Current?
It looks like you're trying to manually construct a poor man's IoC framework to be honest.
Consider doing some research on Unity/Ninject and see for yourself why strongly-typed decoupling is better.