throw new
Error("Unhandled Error in Silverlight Application Cannot resolve TargetName contentPresenter.
at MS.Internal.XcpImports.VisualStateManager_GoToState(Control reference, String StateName, Boolean useTransitions, Boolean& refreshInheritanceContext)\n
at System.Windows.VisualStateManager.GoToState(Control control, String stateName, Boolean useTransitions)\n
at System.Windows.Controls.Primitives.ToggleButton.ChangeVisualState(Boolean useTransitions)\n
at System.Windows.Controls.Primitives.ButtonBase.UpdateStateFlags(Boolean disable)\n
at System.Windows.Controls.Primitives.ButtonBase.OnIsEnabledChanged(IsEnabledChangedEventArgs e)\n
at System.Windows.Controls.Control.OnIsEnabledChanged(Control control, EventArgs args)\n
at MS.Internal.JoltHelper.FireEvent(IntPtr unmanagedObj, IntPtr unmanagedObjArgs, Int32 argsTypeIndex, Int32 actualArgsTypeIndex, String eventName, UInt32 flags)");
Turns out, it wasn't throwing an error based on the button being used to fire the event/open the window nor was it the window itself. It was another control on the page that had a "contentPresenter" that didn't even communicate with the window itself.
It seems that the child window (modal since it is Silverlight) sent all of the controls that were active on the page into the disabled state - and ONE of them had the issue with not being able to find "contentPresenter". So, it was the one user control... all the way over to the right and not talking to the child window that was being the problem child after all.
No comments:
Post a Comment