Vibe Coding an XrmToolbox Tool part 4 - Optimisation and destroying my entire tool

There may be an elephant in the room here, but I'm going to start with the optimisation. During my testing for the tool, I noticed a bit of lag when loading different pages. The initial load of flows is fine, because this is the first load of an entire environments flows and metadata, but I noticed when I was going in and out of menus, it seemed like it was reloading the entire list of flows all over again. I popped over to Copilot and asked it about the code and if it was reloading the flows each time, spoiler, it was. So I thought about some changes we could make, we would still want it to reload changes, but we might not want it to reload all flows all the time, especially if an environment has a large number of flows. Great opportunity to create something configurable, like a settings menu.

I asked Copilot to implement a settings menu with a different functionality, don't refresh the flows, refresh just the flow that was changed and refresh the entire list.

Not only did Copilot manage to do this, complete with a menu button on the ribbon, but generated the menu with a radio button, allowing only one selection (without a specific prompt to tell it to do this) and it applied to settings to all the dialogs. This means when either the Manage Co-owners or Manage Solutions is selected, the functionality kicks in, which is great.

This also utilises the settings manager in the XrmToolBox. Basically this is a way to save a settings file per tool, so that the XrmToolBox handle them and then the tool can pull the settings from it. That's pretty cool. This is one of the fun things that I've learnt from this experiment, it's teaching me more and more things about the XTB that I never knew and giving me a new perspective on building and using tools.

This fixes the main problem, of the tool not being super optimised, but I noticed other things too. When changes were being made to a solution or co-owner, the tool would appear to "lock" up and then give you a success message after. But I had been reading about XrmToolBox tools and one of the tips was to show an indication bar to show something is happening and not just the tool locking up. I prompted this and added it to both manage dialog actions. While not necessarily a optimisation, it's more of a user indications, that optimises the experience for people 😅

This is all great and I'm starting to feel really good about this tool, but as I now have aspirations of releasing this, and how I'd want this to be open source, the fact all my files and the snippets of code mention "MyPlugin" (from the template I started from), I wanted to see if there was a way I could change this. I'm smart enough to know that I can't just do a Ctrl+F and find an replace all the code or just rename the files, so again, I asked Copilot about how to go about this safely.

Copilot said I could do it safely and I needed to make several changes and needed to do it carefully. It gave me a list of instructions and asked me what I wanted to change, files, classes, namespaces etc. I told it I wanted to rename everything, I wanted to eliminate all trace of MyPlugin and replace it with Flow Solution Finder. I asked it to do the changes....and this is where Copilot died. I restarted VS and tried again and it seemed like it partially did the rename, but again, I asked it to continue on with the rename. Copilot died again. It was at this point that I felt like I'd made a mistake, there seemed to be something about this command that Copilot could not deal with (or there was some sort of outage or something else going on) and I decided to try and recover the project, but when I tried to rebuild, all new outputs failed, they wouldn't load in the XrmToolBox at all, there was just a random error.

But errors are good, errors Copilot can handle. I described the problem, pasted the error and asked Copilot to fix it. Copilot tried and tried and tried, and I tried and tried and tried, but it was no good, it couldn't fix it or create a mechanism to capture more detailed logs.

I tried multiple things, I even asked Copilot if I should just rename my project back, but between all the different places renaming would have to occur, and the different variations of the names, I didn't think that even if I just did this manually, I would be able to do it and have it work.

But it's OK, we can just restore from a backup right....RIGHT? Well 🤷 no, source control was something I was planning to implement later, when I had a stable app and when the code was right. I was very wrong with this idea, this was a bad idea. I understood the concept of source control, I understood that backups are important, yet I still ignored it. And now my tool was broken and this was the end of my experiment. This is one of the things I talk about when it comes to Citizen Development or Vibe coding, how you can, without the right experience, do the completely wrong thing. I had no experience with renaming code like this, and by using a combination of myself and Copilot, I made something in a complete mess that I couldn't bring back and with no source control or backup, I could not restore this tool. 😭

I hope you enjoyed this little journey into Vibe coding and my experiment making an XrmToolBox tool, something I didn't think I could do, but with my tool now broken, this is where it ends....or is it? Maybe not, but catch the next post on what came next.

Ciao for now

MCJ