POC providing a shell for dialogs to work within.

[BillKrat]

I created a POC with the objective of providing a shell for the dialogs that can be easily integrated into existing code. I applied it to the ReverseEngineerHandler class - I provide an edited clip of its usage below. I planned on removing the X window button and replacing it with one that invokes the .Hide() and adding a spinner but I figured I had enough to prove out the concept to see if you are interested in moving forward with it. If you are then we could have design discussions on how the shell should look. If not, I'm content with using it as-is as it will not be feasible for me to maintain a separate branch.

Demo.mp4

[ErikEJ]

Could you explain more about the purpose of this?

[BillKrat]

The purpose is to improve the developer UX. In my initial use I wasn’t sure anything was actually happening; it wasn’t until I examined code that I realized it was updating VS status bar. In light of its effectiveness the UX takes a back seat - this “POC” demonstrates that level of effort could be small to improve it (if this is a concern).

[ErikEJ]

I am so sorry, still do not understand. Are you talking about the debugging experience??

[BillKrat]

No, normal developer usage. When I first used it, the first dialog appeared and after I configured connection it disappeared; it was not apparent that something was happening. When the subsequent dialog appeared then I quickly figured it out, but as I clicked each dialog I was unsure if something was happening until another dialog appeared. On clicking the final dialog I was pleasantly surprised to find the context and all files available - very very nice... As a developer I was not accustomed to the flow (of disappearing dialogs; a casualty of the MVVM widget pattern I suspect), now that I'm aware that the visual studio status bar is talking to me, I am more comfortable with it. This was my stab at seeing if a main shell could maintain visibility throughout the processes. I was able to prove this out, that it could be done with minimal code changes to see if you were interested in it.

With all of the work I trust you have on your plate, and judging by your responses, it seems this is a non-issue (UX) and you can feel free to abandon the PR. Had it been a consideration, I was offering my time/talents to assist via this PR to get it ready for primetime [after collaboration, reviews, and testing].

Thank you for your time! The project was appropriately named!

[ErikEJ]

Ah, get it now.

What would really make a difference would be to wrap the reverse engineer dialogs in a Wizard similar to the old EDM Wizard: https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions-1/models-data/creating-model-classes-with-the-entity-framework-cs

That would be a marvellous UX improvement.

[BillKrat]

Ah, yes - that would be. If you wanted to create a branch for this purpose we could collaborate on achieving that goal. It would require a medium effort where we [I] would turn your handlers into Presenters, dialogs into controls, and add logic to support the new flow - for a pattern I coined MVP-VM. You have all the hard work done, we just need to tweak the framework to improve the UX.

Note: In 2000 Andy Bower co-authored the Twisting the Triad paper noting the short comings of MVC [MVVM] which resulted in the MVP pattern emerging. WPF early architects skipped this chapter in our history so MVVM never evolved; thus it remained a "widget" versus "framework" pattern. I consulted with Andy while writing the below article in 2011 for accuracy.

https://learn.microsoft.com/en-us/archive/msdn-magazine/2011/december/mvpvm-design-pattern-the-model-view-presenter-viewmodel-design-pattern-for-wpf

Andy Bower's article describing the need to evolve follows:
TwistingTheTriad.PDF

[ErikEJ]

@BillKrat I would be great if you would want to contribute here, my contributions in this area will be quite limited, as @sm15455 did all the hard WPF work here.

[ErikEJ]

@BillKrat And maybe it would be a good idea to start by creating a GitHub issue here to discuss scope and design for this very useful addition to the tool.

[BillKrat]

That is a good idea, I’ll create an issue as you suggested. Before I do that, I’ll create a POC with a wizard that demonstrates the behavior you are seeking. The navigational bits will work but functionality will need to be bolted in, I’ll bring some UML in along for the ride (when I create issue). This will let interested parties evaluate scope and design without the distraction of the pattern (it will speak for itself)

The current POC was from context of minimal work/impact (took me a day). The next one, not so much; may take a few days. I’ll tentatively plan to have it out there by the 18th (next Monday).

[ErikEJ]

This is highly appreciated, and there is no rush or deadline here!