Is there going to be something like this for visualizing visual trees in
Avalon at run time though the debugger?
-Brandon
What do you envision this doing? Just showing a treeview heirarchy of the
visual tree with basic positional/size detail? Sounds like a fun project
to work on and I could probably bang something out tonight.
Latwer,
Drew
Exactly, although I was thinking something that would ship with Avalon,
but a 3rd party component would be just as good for me.
Let me know how that goes. Would you release the source for whatever
you get done tonight? I'd like to see how these things work.
> Exactly, although I was thinking something that would ship with
> Avalon, but a 3rd party component would be just as good for me.
Yeah, this would just be to hold us over until then... or in case they don't
ship one.
> Let me know how that goes. Would you release the source for whatever
> you get done tonight? I'd like to see how these things work.
Sure, I'll post up binary and source. It should be simple, I already have
a function I use to dump a visual tree to the debug window I just need to
host it in a visualizer and hook up a little tree view action and it should
be useful for everyone. :)
Later,
Drew
I got started late on this tonight due to "real" work invading my play time.
;)
Anyway it's gonna take a little longer than I originally imagined because
the Visualizer architecture requires you to serialize the data from the runtime
out to the debugger (meaning I can't just work directly with the Visual reference).
So I need to decide exactly which details I want to display, define some
datastructures around that and then expand the visual heirarchy into an object
graph of those datastructures. Still not that much work, but to get it to
be useful I need another hour or so with it to get a basic architecture working
and then I'll be able to plug in type specific detail generators for types
from Visual all the way up through your own custom Control.
Later,
Drew
I look forward to seeing what you come up with. I think it could be a
very useful tool.
-Brandon
> I'm not sure I understand what you were saying about serializing the
> data, but that's because I've never looked at how the visualizers
> work. Are you saying that you cannot provide a graphical
> representation (ie, listview), but instead only provide a text based
> tree within the watch window?
No, I can represent the data however I want visually. What I'm saying is
that the Visualizer architecture is dealing with a *copy* of the data that's
actually in the instance. This is usually done by serializing the data type
across the boundary, however since a Visual is not serializable I have to
create my own datatype to hold the pieces of data I'm "interested" in showing
in the Visualizer. It's easy if I was working with a string or an int or
Hashtable or DataSet because they all serialize.
> I look forward to seeing what you come up with. I think it could be a
> very useful tool.
Me too. I'm actually pondering three diff. Visualizers: Visual Tree Viewer
(for all Visual subclasses), Logical Tree Viewer and XAML viewer (both for
FrameworkElement subclasses). I'll deliver in stages of course... should
have the visual one working tonight.
I think I understand it now. Isn't XAML how you would serialize it?
Does SaveAsXml() from the parser in Serialization allow you to serialize
all the visuals you need? If so, would you be able to use this instead
of making custom data structures to hold the data you want? I really
don't know enough about this stuff yet, but I thought I'd though that
out there after reading the SaveAsXml thread from this newsgroup.
> I think I understand it now. Isn't XAML how you would serialize it?
I could, but it depends on what information I want. XAML only gives you the
definition which doesn't necessarily contain all the the runtime info. Something
like the FrameworkElement.ActualHeight/Width properties, things I'd probably
like to see during debug, aren't available in XAML.
> Does SaveAsXml() from the parser in Serialization allow you to
> serialize all the visuals you need? If so, would you be able to use
> this instead of making custom data structures to hold the data you
> want?
Yes it entirely possible to use the result of the Parser as my datastructure
(either XAML or BAML). However like I said, I would lose any runtime only
info if I did that. That said, the one Visualizer I'm going to write is going
to do exactly that. Should be the easiest one to write, depending on how
fancy I try to get with the XAML output. :)
> I really don't know enough about this stuff yet, but I thought
> I'd though that out there after reading the SaveAsXml thread from this
> newsgroup.
We're all learning this stuff together. ;)
Later,
Drew
Unfortunately I wasted most of my time battling with the XAML Viewer and
never got it working due to some funkyness with the IVisualizerObjectProvider.
I was streaming the XAML straight to the Stream, but when I go to call GetData
I get some stupid bug bitching about MemoryStream is already closed (thing
it's a bug in the Visualizer architecture).
Another thing I realized is that I'm using the Nov CTP of Visual C# express
which apparently uses an outdated Visualizer architecture. The changes to
the code are really simple, but people won't be able to just grab the source
or binary and just go on Dec CTP builds unless I upgrade and tweak for the
changes.
In other words, the Visualizer stuff is holding me back more than the Avalon
side of things. :)
Later,
Drew
[1] http://code.hackedbrain.com/images/VisualTreeViewerVisualizer.png
Ran into another snag with the visual tree visualizer which is that simple
structures like System.Windows.Length are not marked as serializable, therefore
when I try to store there values to cross the visualizer boundaries I get
serialization exceptions. I don't see any reason for them to *not* be serializable
by release, but in order to get this all working I would have to cut out
transporting those values (which would make the visualizer almost useless
since it wouldn't have good details) or I have to start writing my own serialization
surrogate plumbing (not fun). Something that should be so simple is turning
out to be a pain in the butt, but isn't that always the case? :P
Later,
Drew
[1] http://code.hackedbrain.com/images/XAMLDumpVisualizer.png
Also, would System.Windows.LengthConverter help? I've never used it,
but it sounds like it could.
-Brandon
"Drew Marsh" <dru...@hotmail.no.spamming.com> wrote in message
news:dru...@hotmail.no.spamming.com: