Hi,
I’m currently having an issue with GoWPF (tried 1.0, 1.1 and 1.2), and even though I may not be the cause, it’s somehow involved…
My application is a VSX addin. It works fine, except when some WPF is used elsewhere. For example, in a scenario I have a Diagram (goXam) in the main window, I create and show a Wpf Window, close it, and right after, clicking anywhere in the diagram bring the following exception:
System.NullReferenceException was unhandled
Message=“Object reference not set to an instance of an object.”
Source=“Northwoods.GoWPF”
StackTrace:
at Northwoods.GoXam.Diagram.FindDefault[t](String name)
at Northwoods.GoXam.Part.UpdateSelectionAdornment()
at Northwoods.GoXam.Part.UpdateAdornments()
at Northwoods.GoXam.Part.#Nh(DiagramPanel panel)
at Northwoods.GoXam.DiagramPanel.#Ho(HashSet1 invalids, HashSet1 delay)
at Northwoods.GoXam.DiagramPanel.#Ho()
at Northwoods.GoXam.DiagramPanel.ArrangeOverride(Size finalSize)
at System.Windows.FrameworkElement.ArrangeCore(Rect finalRect)
at System.Windows.UIElement.Arrange(Rect finalRect)
at System.Windows.ContextLayoutManager.UpdateLayout()
at System.Windows.ContextLayoutManager.UpdateLayoutCallback(Object arg)
at System.Windows.Media.MediaContext.InvokeOnRenderCallback.DoWork()
at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
InnerException:
Any idea what could be causing such a behavior? Note that the WPF can be in the same assembly, it does not matter. I’m currently trying to have a small sample to show this, but no luck so far in isolating the trigger.
I realize this is a long-shot, but any hint would be more than welcome…
Thanks.
B.
That doesn’t look like an error that I’ve seen or heard of before.
The Diagram remains visible the whole time, right?
Is this VS2008 or VS2010? VS2010 has lots of WPF usage all the time.
Here’s the call to Diagram.FindDefault:
DataTemplate template = this.SelectionAdornmentTemplate;
if (template == null) template = Diagram.FindDefault<DataTemplate>("DefaultSelectionAdornmentTemplate");
Here’s the definition of Diagram.FindDefault:
public static T FindDefault<T>(String name) {
ComponentResourceKey key = new ComponentResourceKey(typeof(Diagram), name);
if (Diagram.DummyFrameworkElement == null) Diagram.DummyFrameworkElement = new FrameworkElement();
Object item = Diagram.DummyFrameworkElement.TryFindResource(key);
if (item is T) return (T)item;
return default(T);
}
private static FrameworkElement DummyFrameworkElement { get; set; }
The private static variable is neither used nor set anywhere else.
Yes, the Diagram remains visible.
It’s VS2008.
I figure it’s not an issue with goXam as much as it is an issue with WPF (or my use of it), but this is the only clue I have so far… And from the look of it, it does not help much…
I’ll continue digging…
Thanks,
B.
I was able to get a pretty simple project. I can’t vouch it’s the exact same behavior, as the exception is hidden, but I’m betting it is.
Here is what I did:
1. create a new Extensibility Addin Project, w/ Tools menu item and load at host start
2. create a new Wpf Control library in the same solution
3. create a usercontrol using gowpf (I used ClassHierarchy, from the gowpfdemo), compile it
4. create a Form in the Addin project
5. embed the usercontrol in the form (through a ElementHost)
6. modify the Connect::Exec() method to create and show the Form.
7. Run the addin
Once the VS shell is started, in the Tools menu, click on the AddIn entry.
The form appears, showing (in my case) the GoWPF class diagram.
Click on any node, the Form closes without any catchable exception.
I can send you the whole solution if needed.
B.
To follow-up.
I did reproduce the issue, it is indeed is the same behavior.
I removed the ElementHost component from the equation, accessing the diagram from inside a wpf window causes the crash.
So it now appears that GoWPF crashes when used in an VSX Addin.
Any idea what the difference of using gowpf in an vsx addin versus a standalone application? Any help would be appreciated.
Thanks.
B.
Your case uses VS2008.
Does it happen in VS2010 too?
Hmmm, my initial evaluation is wrong.
There is a different behavior between the 1.0, 1.1 and 1.2 versions.
1.0 always fail.
1.1 and 1.2 have a different behavior. I’ll make more thorough tests, as some cases seem to work fine, while others have problems.
I’ll get you back when I’m done.
B.
Found the problem.
Actually related to another problem I had previously, I should have remembered it…
It is related to the following issue
Not really sure yet how to solve this : my component has to know whether a WPF application is already running or not before loading the package, so the goWpf license key is entered correctly… I’ll have to think it over, but at least I now know the issue.
Thanks,
B.
Found a solution.
Turns out that all I need to do is create the Application in another thread, instead of the current (main) one.
It has the side-effect of changing the Application name used for the goWPF license, but this is easily solved at least.
So up and running again.
B.