Hi,

Up until the June CTP, I was able to trap events from elements inside a InlineUIContainer, e.g.

// Wherever you create the InlineUIContainer

Canvas can = new Canvas();

can.Width = 80.0;

can.Height = 20.0;

can.Background = Brushes.Blue;

can.PrevewMouseMove += ........

InlineUIContainer uiCon = new InlineUIContainer(can);

This used to work find as any delegate added to the elements (even though the InlineUIContainer was "Disabled") would fire. Now it doesn't. Can someone please help me?

Thank you very much,

Jaco

I would expect the behavior you're seeing is in the context of a RichTextBox. In earlier builds, it was possible to enable UIElements embedded in RichTextBoxes, but in recent builds (and in RTM), embedded UIElements are always disabled when placed inside RichTextBoxes. And when disabled, they don't receive UI events.

You could work around by placing the FlowDocument in a FlowDocumentReader. However, with this workaround the user won't be able to edit the content.

Another idea is to attach your PreviewMouseDown (or whatever) handler to the RichTextBox itself, then use hit testing (RichTextBox.GetPositionFromPoint) to detect a mouse move over an element you care about.

Ben

The thing is, the InlineUIContainers was disabled in the Beta 2 release, and yet, with the elements disabled I was able to trap the events from the elements contained in a InlineUIContainer.

Well if there really isn't a different way, can you maby supply a little sample showing the hit testing scenario?

Thank you very much,

Jaco

I don't have an explanation for the beta 2 behavior.

With the latest bits, you should be able to do something like this. This is off the cuff code, no guarantee it's bug free .

void OnMouseMoveListener(object sender, MouseEventArgs e)

{

TextPointer position = richTextBox.GetPositionFromPoint(e.GetPosition(richTextBox), false /* snapToText */);

if (position == null)

{

return;

}

UIElement uiElement = position.GetAdjacentElement(position.LogicalDirection) as UIElement;

if (uiElement != null && IsInterestingElement(uiElement))

{

DoSomething();

}

}

The basic idea is that position will be adjacent to whatever the mouse is over. Its LogicalDirection property tells you if the content hit precedes or follows the pointer.

Ben

That is very strange, so is there any reason why the control inside the InlineUIContainer can't be disabled, but still fire events? (I know its a bit over reaching, but I have to try).

So other than the example you suggested, there is no other way? (I am not ungrateful, I appreciate all the help, but there is a certain distaste of trapping events like the way described, it is way to error prone)

Thank you very much,

Jaco

It's a feature of disabled controls that they don't receive events. Otherwise the control owners would have to add property checks to their decision tree.

The fundamental problem here is that RichTextBox has a very poor story for embedded UIElements, or custom TextElements. We didn't have the resources to make this work in V1, so you're left with distasteful workarounds like what I suggested. You'll run into additional problems, in particular clipboard operations like cut and paste drop all UIElements other than Image. You can work around that by handling cut and paste yourself, but again it's a very poor story.

Ben

O well, thank you very much then. If there is no other way, I guess the workaround is much better than having no solution at all! :)

I thank you for all you're help.

Jaco