Hi,

>this would mean that the adorner is about to get the same size than the adorned element. This is of course sometimes the case, for example, if you create an adorner for re-positioning the whole adorned element. But if you want to create an adorner for re-sizing your element, the adorner would be very small. Just in this case you'd need both widths.

OK. Following my last post I've now got an instance where the desired sizes of the AdornedElement and the Adorner differ viz. a TextBlock element with some arbitrary text in it.

As the size of the AdornedElement is reduced below the minimum required to display the contained text I see that the Adorner.DesiredSize sticks at the area neccessary to display the complete text. Using the sample code (which uses the mixture of the Adorner and AdornedElement DesiredSizes) the resizing operation then falls apart with the display becoming erratic. The relevant line from the ArrangeOverride method in the sample code is:

topRight.Arrange(new Rect(desiredWidth - adornerWidth / 2, -adornerHeight / 2, adornerWidth, adornerHeight));

(where desiredWidth/Height is derived from the AdornedElement.DesiredSize and adornerWidth/Height from the adorners DesiredSize)

However if I base all the positioning logic on the AdornedElement.DesiredSize (i.e. disregard what the adorner is telling me) the behaviour is as expected. So all I seem to have discovered is that attempting to use the adorners DesiredSize() in this way is counter-productive.

UPDATE: I take back the last para. Regardless of how the thumb positioning is specified the display only updates properly if both the width and height are modified. If just the width or just the height are changed the thumbs tend to stick in their current location and the visible text shrinks to a greater extent than required. I seem to remember coming across similar behaviour in GDI in the past - maybe this is a pretty low-level problem.
(I've got simple repro code if anyones interested...)