Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
"Visual Bridge" for items outside the visual tree #352
I've been using Caliburn for a while now, and one problem that still trips me up is working with controls that aren't part of the main visual tree: context menus, popups, etc. I've avoided these controls as much as possible because of the pain they present.
I've been doing some searching for how to solve the popup issue because I'd like to use WPF ToolBars in my current application (the automatic overflow feature is extremely handy). However, I have a hierarchy that makes it difficult to target the proper method since I rely on Caliburn's action bubbling to find the right context. I haven't been able to find a solution that preserves the visual tree bubbling; most solutions simply set the action's target, but I need the target to be the screen and the tool bar is in a data template several layers away from the screen with no reference to the screen that hosts it.
To solve my problem, I created a simple attached property for a "visual bridge" - a way for a control to specify a "visual parent" directly, and I replaced Caliburn's
The only change to the
With that said, I'm wondering if this would be a useful addition to the Caliburn project, or if there's a different method for handling these situations that would be preferred. I'm unsure if this would work on more than the standard .NET WPF platform.
If this is a worthwhile addition, I'd be happy to make a pull request, though I've never done that and I might have to fumble my way through it... (And there may be a better name than "VisualBridge".)
Interesting, the whole "things not in the visual tree" is something most people get caught up on.
Will have a think about what it would mean to include it in the project, ideally it should work everywhere. One way may be to add an extension point so that behavior can be customised and usage of something like
Being able to adjust how Caliburn bubbles up the visual tree could be just as effective. In this case, some way to tell Caliburn how to get an element's parent, with the default method being
I've been bit pretty hard by this issue as well.
I had some time today so I decided to dig into this.
Turns out, I was able to intercept the SetMethodBinding via the normal channels and "extend" it's functionallity a little to accomodate those cases where No action target was found as a result of this whole VisualTree thing.
Have a look
I'm reusing all the base SetMethodCode, just attempting the search first from the initial control source, and if that doesn't work, look for a PlacementTarget, and if I find one, continue the search for a valid target at that point.
I'm sure there's edge cases to contend with, but so far, this code seems to "just work", and with 0 impact on existing Caliburn.