Crack + Snoop

Apr 6, 2009 at 7:19 PM
Saw your post (http://groups.google.com/group/wpf-disciples/browse_thread/thread/4f2210616a8ab501/03cb12859b4b9386?show_docid=03cb12859b4b9386) in the WPF Disciples group ... and wanted to thumbs up the idea.

I would love the Ctrl-Shift behavior in Crack.NET.

I don't think you need to limit how much the user can see of the element tree ... but if you do, make sure it is configurable. Given that though, I like the idea. It would just be icing on the cake.

Another thing I like about Snoop is seeing the visual that I'm 'cracking' or 'snooping'.

By the way, love the blinking alien. It is just pure coolness. I know that it is just a simple flip book animation, but it is still the bomb.
Coordinator
Apr 6, 2009 at 7:27 PM
:)  Thanks for the feedback! 

Part of the reason I need to limit the size of the Element TreeView (aside from having it be too heavy), is that WPF has an artificial limitation where you cannot nest elements more than ~255 levels deep.  Since TreeViewItems nest within each other, this limitation can become a problem (in rare scenarios).  Limiting the number of descendants/ancestors allows me to present a lightweight, safe view of the element tree.

Yeah, the blinking alien is the bomb!
Apr 6, 2009 at 7:38 PM
Again, thanks for the prompt reply ... and, yes, that's right ... good point ... in fact, I know that Mark Kharitonov has previously contacted you about an improvement he has made in Snoop (and was suggesting for Crack.NET) due to the nesting limitation.
Coordinator
Apr 6, 2009 at 7:41 PM
Kharitonov's solution is fine, but I didn't like the user experience it creates.  I'm thinking more and more that limiting the number of elements in the TreeView is the ideal solution.  Once I get a prototype working, I'll let you know and hopefully you'll agree with me.
Apr 6, 2009 at 7:59 PM
Oh, I'm not pushing for Kharitonov's solution ... although I do like that he fixed the limitation in Snoop ...

From what I understand, I already like your solution. :) What would be interesting and fun would be some neat way from design standpoint to change how much of the element tree you are displaying ... maybe something akin to zoom. Who knows, maybe you could hook in the mouse wheel ... that would be a slick way to 'zoom' the element tree larger and smaller.

One tool to rule them all,
One tool to find bugs,
One tool to bring them all,
And in the darkness squish them.

:)
Coordinator
Apr 6, 2009 at 8:04 PM
I was thinking about having a "zoom slider" to change the number of elements in the TreeView.  Mouse wheel support is a cool idea, too.  Thanks, I'll probably add that in. ;)

Your poem resonates with me.  I want Crack.NET to be The Tool for WPF devs.  I have so many features in mind for it, but adding in element tree sniffing is definitely the highest priority work item.
Apr 6, 2009 at 11:55 PM
I love this idea! I dislike how the current state of snoop has broken the property changing ability! But alas, I use an older version of snoop on a near daily basis, and if crack implemented this capability then I would surely use crack all the time!!! (the green alien with a blinking eye application, not some other reference).

thanks for all your hard work josh, it is certainly appreciated!
Coordinator
Apr 7, 2009 at 12:13 AM
Hey aquaseal, you're in luck. Part of the next planned version of Crack.NET is to have the ability to edit properties in Memory Explorer.  I think it will be something like what Mole exposes for property editing.  We'll see how it goes...
Apr 7, 2009 at 12:14 AM
aquaseal: If you look at the following post (http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/b99f3db7-540c-43f4-8051-69d2d51a78bc) you will see how Mark fixed property editing in the latest version of Snoop.

And I agree, I would rather use Crack (oh, that is so fun to say).
Apr 7, 2009 at 1:04 AM
Thanks guys! That's great to know!!! Can't wait for the next version!