Geek Answers Handbook

Silverlight: FrameworkElement.FindName () does not find the control if it does not appear in the browser window

I have a problem when I use the "FindName ()" method of a FrameworkElement object to find the child control of this element.

There is an interesting behavior that I noticed and cannot understand. If the user scrolls the browser window so that the control itself is not noticeably displayed in the context of the window frame, then "FindName ()" does not return the element. However, if this control is visible in the window frame, it finds it in order.

Is this a known issue? Has anyone else come across this before?

I am not talking about the Visibility property of a control. The Visibility property is set to Visible.

Update I tried setting VirtualizingStackPanel.VirtualizationMode = "Standard" in the ListBox control (which is the container I'm looking for), and it still could not find the specified control.

+4
source share
2 answers

If you use such a Silverlight Spy tool, you can try to find the control manually.

If this is not the case, perhaps in the virtualization stack panel .

+2
source

If you understood correctly that you say that when the control scrolls from the ViewPort application, then although the visible property remains valid, FrameworkElement.FindName ("") cannot find it.

I assume that you have worked through all the basics of re: Xaml scoping, etc. If you add controls dynamically, you are sure that you are coming from the correct parent element, etc. If so:

Using RedGates Reflector, we see that FrameWorkElement.FindName is implemented as follows:

public object FindName(string name) { return XcpImports.DependencyObject_FindName(this, name); }

XcpImports.DependencyObject_FindName is implemented as

 [SecuritySafeCritical] internal static DependencyObject DependencyObject_FindName(DependencyObject referenceDO, string name) { int num; IntPtr ptr; CheckThread(); if (name == null) { throw new ArgumentNullException("name"); } uint hr = FindNameNative(JoltHelper.Context, (uint) name.Length, name, referenceDO.NativeObject, out num, out ptr); GC.KeepAlive(referenceDO); if ((hr != 0) && (hr != 0x80004005)) { throw Error.MarshalXresultAsException(hr); } return (DependencyObject) ConvertDO(ptr, num, true); }

So, if you do not encounter an exception, I think the most interesting line is probably:

 uint hr = FindNameNative(JoltHelper.Context, (uint) name.Length, name, referenceDO.NativeObject, out num, out ptr);

What is included in the native code and is determined using the dll import in XcpImports:

 [DllImport("agcore", EntryPoint="FindName", CharSet=CharSet.Unicode)] private static extern uint FindNameNative(IntPtr context, uint cString, [MarshalAs(UnmanagedType.LPWStr)] string name, IntPtr referenceObject, out int typeIndex, out IntPtr obj);

Not to be confused with Developers Express AgCore.

This article about ZdNet (circa 2007) by Ed Burnett:

http://www.zdnet.com/blog/burnette/dissecting-silverlight/297

Says that:

agcore.dll (2.2M installed) is the main ActiveX control that is responsible for rendering and Silverlight events, including audio and video decoding.

It also says that:

npctrl.dll (460K) is a wrapper for agcore.dll that makes it work inside Firefox.

So my first question. Is your problem consistent in every browser? Perhaps this is the shell for agcore.dll in some browser / version, which is the problem, and not the core technology (agcore.dll).

+3
source

More articles:


All Articles