Keeping function/method when switching decompile-to language?

[tamlin-mike]

Would it perhaps make sense to keep the function where the cursor is in view (and unfolded) when switching from e.g. C# to IL?

While I don't view it as a major problem, since it's a not too frequent operation for me personally, I did find it somewhat irritating to lose focus of the task at hand (not to mention trying to remember the method name so I could search for it in IL view :-) ).

Just an idea.

[greenozon]

Very nice idea!
I believe that real product consists of small tiny but userfirendly bits

definitely one of those 👍

[christophwille]

Maybe we should start a discussion thread "Death by a thousand cuts" for those small annoyances (that add up)?

[tamlin-mike]

That's not a bad idea. I would probably consider a slightly more diplomatic subject line :-), but have a single thread listing all the small things (and the first or second post being updated to keep them in one or more lists) definitely sounds like a good idea to me, if it can help giving a better overview.

[tamlin-mike]

To add to the list:

switch-decompilation. Place default case last. Always.

[siegfriedpammer]

Usually we sort the case blocks by their StartILOffset, if no IL range is applied to the instruction, it is 0 and naturally comes first. If you have a concrete example where we produce such code, please open an issue. Thanks!

[tamlin-mike]

Siegfried, I have tried reproducing this with C# only transformed by the Microsoft compiler, and... utterly failed. :-) It would seem the problem is introduced by a 3rd party transformation tool (Fody "weaver", obfuscator, deobfoscator, whatever). I'll try to find the time to look into the IL and see if there's anything ILSpy can do about it. If not, please just disregard this one.

[siegfriedpammer]

Mike, I have fixed a couple of bugs in the area of switch statements recently, so it might be worth trying with an older version, if you try to reproduce the problem. Also, it might be interesting to look at "impure" IL, i.e., IL generated/modified by tools other than the C# compiler. There's always the possibility that we forget to move IL offsets when transforming. Thanks!

[siegfriedpammer]

a6bbcca is the commit I was referring to.

[tamlin-mike]

No, this problem goes back a looong time (years), including switching on plain integers, like
struct vec3f{ float x,y,z; float GetComponent(int idx) { /* obvious implementation */ } }

If I find the time, I'll boil down an ilasm-usable case and open an issue for it. Even if unfixable, maybe it could be good to have as a reference for... something.

[tamlin-mike]

"Dimming" of selection marker when control not in focus
I can't count the number of times I have switched from C# to IL (or vice versa), looked at the tree view and see an item selected and then try to do some keyboard interaction to either move selection to something else in the tree view, or expand/collapse a node, using keyboard cursor keys, and go "Aaargh!" when instead of getting the expected result the decompilation view switches to e.g. "IL with C#".

It would be good if the tree control changed highlighting type of selected item when the control loses keyboard focus.
If done by actually dimming the highlight (e.g. RGB*2, or Alpha=0.5 if really wanting to waste resources) or replacing the XOR with an outline or something completely different is unimportant. Being able to at-a-glance see "not in focus" is important.

F6 - Toggle Pane
While on the subject of keyboard interaction; In Windows, since decades F6 has been the keyboard shortcut to switch panes (and/or "views", cmp. document split-view in VS). I'd really like to see F6 toggle between the two main panes (treeview <-> whaveter view happens to be visible in the righ pane). Ctrl+TAB + manually reading, identifying, selecting and finally activating a different view is just too cumbersome to even bother with when one knows there is an established keyboard shortcut for this, and it's in your muscle memory.