Hmm... I think I understand what you are getting at, but the Windows
SDK doc clearly says for FrameworkElement.RemoveLogicalChild():
Removes the provided element from this element's logical tree.
I also just saw the ChangeLogicalParent() method. Am I to assume that
this also exhibits the behaviour that you describe?
If what you are saying is true, then what do I really need to do to
insert a new element right underneath the window in the logical tree?
The LogicalChildren property only has a get on it, and returns an
IEnumerator. That essentially means that there is no way to control the
logical children except through API methods provided which apparently
don't work. Is this something that I just shouldn't be doing and MS
doesn't want us to do?
To give you some context, I'm still trying to find a way to be able to
scale a borderless window up and down (This is one of 3 approaches that
I'm trying now, blocked on all 3!). I've found that if you used a
viewbox, the windows scales up and down nicely. However, I don't want
to use a viewbox all of the time, as I don't always want my content to
be scaled to the window size. So my idea was to programatically insert
a viewbox in the logical tree at the point that I want to zoom the
window down. Later when zooming it back up, I'd programatically remove
the ViewBox from the tree.
Does this sound crazy?
Michael Latta wrote:
> The calls you are using are for managing the logical tree from within a
> component. They exist mostly to notify some parts of the system that you
> have already removed/added children to the tree. They do not perform the
> add/remove. The management of children for the tree is the responsibility
> of each element class, and in the WPF provided elements this is mostly at
> the leaves not the common abstract classes. There is no single call to make
> to add/remove from the tree. You need to test what kind of element it is
> and use the proper child/children properties. For example a Panel has its
> children in the Children property which you may use to add/remove children.
> The Adorner classes use a single Child property. You need to look at what
> Window exposes for managing the children in your case and code to that.
> Also note that the collection under an enumeration may not be modified
> during the enumeration, so even had it been possible to do what you had, it
> would blow up when the enumeration attempted to access elements after the
> remove operation. This sometimes means that you need to create a temporary
> collection to hold elements that are to be removed/added while iterating
> over the children of an element.
> (C# / WPF MVP)
> "Jason Dolinger" <firstname.lastname@example.org> wrote in message
>>Last question for the day (today has been a doozy!):
>>Has anyone successfully used FrameworkElement.RemoveLogicalChild(object
>>child)? I'm attempting to insert a new object into the Logical Tree,
>>right in between the Window and the next level down (which is whatever
>>you've defined at the top level of your tree). The first step of this
>>process is removing that next level down element from the window's logical
>>tree, using the following approach (this code is in the window.cs file):
>>// get the enumerator to the Window's logical children
>>IEnumerator children = this.LogicalChildren;
>>// move the first spot in the collection
>>// Get the first element in the enumeration,
>>// this should be the first element below the window
>>FrameworkElement topLevelLogicalChild = (FrameworkElement)
>>// remove the child from the window's logical tree
>>When I execute this code, the logical tree remains unchanged. While
>>debugging, I've also verified that what I get back from children.Current
>>is indeed the element that I want to remove. Most likely I'm doing
>>something wrong here, but perhaps there is a small bug this part of the
>>API? I wouldn't think that it'd be used all that much.
>>Thanks for any information on this,