Otherwise, great work! Very handy, rolling out to the team today.

As I mentioned, doing sytax-highlighing in the tree will require me to set each node to ‘OwnerDrawText’ mode which means *I* have to take all responsibility (in code) for hightlighting selected nodes, etc. This (obviously) isn’t impossible, but its also (obviously) non-trivial so I will absolutely consider it for a v2 feature toss it into the product backlog — I agree it would be really cool/helpful for syntax highlighting to be used for the treenode text; thanks!

The trouble with having the tooltip show the full method signature is that the tooltip both repeats whats in the node text AND gets ridiculously long, often extending well outside the treeview panel itself (which starts to look poor — trust me, I prototyped it and tooltip text that’s longer than the thing being tooltipped[sic] looks visually too busy).

I’ve decided to meet you halfway on this suggestion: the tooltip text will contain the member type + member accessibility + return type but NOT the name of the element itself or its parameter names.

This will result in tooltips like “Public Variable : string”, “Public Method : void”, and “Private Internal Class” where the RETURN type is always in the tooltip for quick reference but the tooltip itself doesn’t repeat the same info in the node’s own text (except for return type, assuming you have chosen the option to display this in the node).

This approach also helps anyone who cannot immediately recognize the specific icon for ‘protected method’ as being the blue cube with the key icon or ‘private class’ as being the three boxes with the padlock icon imposed on it, which — while clever — isn’t really all that 100% informative

How’s that sound –?

(and thanks for the feedback~!)

I already replace the “old” “Source Code Outliner” with yours, not problem at this time.

Some features, may be cool to have :

1. you give a lot of info, param type, param name, return type… it’s not easy to read. May be use color, like green for the return type, blue for the param type

2. I think the tooltips should be full (param name, param type and return type) all the time and not depending on your setting

Thanks for your job

Ah, I see what you’re getting at now. I think KB navigation of the tree would be an interesting feature (and I understand how it could be useful) but I think its going to move to vNext instead of 1.0 for now.

I’ll put in into my product backlog though — good suggestion (and thanks again).

-Steve B.

Hmm, didn’t know that about the original powertoy, thanks for the pointer.

My thoughts on the key differences came from trying to use the keyboard to browse through the items. At the moment the keys only allow you to navigate the tree without actually doing anything, so I thought about how I would try to make it useful.

My hands tend to prefer resting on the keyboard while I’m thinking.

Thanks,
Jorge

Thanks for the comments — especially the part about expand/collapse selecting the node being expanded/collapsed as that makes zero sense as an intended behavior (and I’ve just now quickly fixed that!).

Re: the various outiner v editor focus ideas, I’m not certain its obvious (unless you are familiar with the existing VS Source Outliner PowerToy which also has this same behavior) but as presently implemented in my prototype single-clicking a node navigates to that element while retaining focus in the treeview but double-clicking a node in the tree BOTH navigates to that element in code AND moves focus to the editor so you can start typing.

Given this existing differnce between single- and double-click, would you still see any use-case for your suggestions re: ENTER or SPACE to move focus back to the editor? Let me know your thoughts and thanks again for the feedback!

But of course I’m not posting just to whine.
Here’s a are some suggestions and some quirks I noticed:
* Clicking in the tree’s ‘+’ and ‘-’ is currently selecting the item;
* Window focus could be used more to the coder’s advantage. I can suggest 2 scenarios:
>> Click with the mouse or typing would give focus to the code window
>> Typing would show the item in the code window while keeping focus on the outliner (and maybe not changing the cursor position?)

Apart from that and the lack of Properties, it seems like it’s coming along very well.

Thanks, and keep up the good work
Jorge

That’s actually a pretty good suggestion — I’ll see how to get the DXCore API to scroll the code so that the selected item isn’t just ‘visible’ in the editor but also moved to the top of the screen…that seems like a pretty good suggestion (and the whole point of writing this myself is so that behaviors in the original SourceCode Outiner that I’m not fond of can be modified).

Thanks for the input~!

-Steve B.