[Save] doesn't 'dim' after a Save, plus ...

[phossler]

Really like it - much easier to use that the original version. Some minor feedback to consider

1. Before opening a file [Save] is dim. After opening, but before making any changes, [Save] is enabled. It seems to me that [Save] should be disabled until the user makes a change (i.e. file is Dirty)

2. After saving, the [Save] button is still enabled. Seems to me that it should be disabled (dimmed) since the file is no longer dirty

3. When opening a file, the customUI.xml 'browser' on the left is selected, but no XML is displayed until the user double-clicks. Seems to me that since customUI.xml is selected on opening, the associated XML should be also automatically displayed

4. [Reload on Save] on the menu bar seems to have an inactive (never active) 'menu selection dropdown' on the right side. Maybe a ToggleButton control would be better (?)

5. Settings dialog [Apply] is always enabled. Seems like that button (and possibly [Accept]) should be dim until the user makes a change, and then go back to dimmed after changes are committed

6. Still haven't figured out the rules behind when [Insert Icons is enabled. Opening file with customUI.xml selected (not displayed Finish creating unit tests for the entire application #3) it's enabled. Selecting existing icon (SC) the menu is not enabled. DC-ing icon it is enabled. Seems like it should be enabled all the time a file is open, and if the file contains multiple XML branches, [Insert Icon] would add to that branch

7. And this is getting nit-picky, but the Circle-X to close a tab seems to be always in the light gray = Disabled. Maybe the active tab could use a red Circle-X, and only the inactive tabs use the current gray.

8. Seems like the user can add the same icon multiple times, but the ID is RDL, RDL1, etc. Maybe a check and if it's there a message: "Icon already there"?

[fernandreu]

Thanks a lot for the feedback! See below my comments:

1. The rule right now is: if you have any item selected, both the Save / Save As buttons will be enabled (this will always be the case as long as there is a document open). The thing is, the tool allows performing external changes to documents you have opened with it (which is why the Reload On Save button exists). Due to this, there could be scenarios where no changes were made inside the tool but you are still interested in saving the document. Not saying there would be many of those scenarios, but here is one (slightly convoluted) example:

   1. You open an Excel file in the tool
   2. You perform some changes and save the file
   3. You open it in Excel and realise something in the cell contents / VBA code is wrong, so you decide to revert it to a backed up version instead
   4. To do so, you close the file in Excel and replace it with a backup one in the Windows Explorer
   5. Since the backup file did not contain the changes you made in step ii, you go back to the tool and click Save again

   Hence, unless I can ensure that there have been no changes both internally and externally, I think I will leave the Save button enabled. I could ensure that by looking at a hash of the file, but that operation might be expensive computationally, and might need to be done quite often. Hence, it might be too much effort for what you gain. Being able to click on a button that doesn't do anything meaningful will always be less annoying that not being able to click on it when you need it.

2. Same comment as above. However, perhaps I can let the user know the save operation was successful somehow (e.g. a message box). Otherwise, the Save button might not appear to be doing anything at all, so they might keep clicking on it without any need.

3. The main reason the first xml file is selected is for the tree view to expand really. I would be more inclined to make it expand differently and select the parent document instead (just in case the tool automatically opens customUI14.xml when the user is interested in opening customUI.xml or an icon instead, for example). One exception to this would be if the document only contains one xml file with no icons, in which case I see no harm in automatically opening it.

4. This is actually not part of the button, but of the toolbar itself (the same way you have four vertical dots at the left of the Open button). This is the typical icon where you can add / remove buttons in a toolbar, but there is no such feature for this tool. I will see if I can hide it.

5. Agree, it shouldn't be difficult to implement.

6. It should be enabled when you have an xml file selected in the treeview. Having it enabled when the document is selected might be a bit confusing if there are multiple xml files. Having it enabled when an icon is selected would be fine because (that icon belongs to a single xml file to which you would be adding icons).

7. This is actually the default style for a close button that I am borrowing from Dragablz (you can see them in the chrome-like example in there). I kind of like them this way; otherwise, I would need another color for when the button is highlighted (it could just be a darker red).

8. Yes, I can do that. Probably a yes/no warning message still allowing you to add it if you want to. Your icon could just be a placeholder to be replaced later, so scenarios where you want to add one icon multiple times are definitely realistic.

[fernandreu]

Everything is implemented except 1&2. I am still undecided in terms of how to show the user that the save operation was successful (a message box seems too disruptive).

However, just looking at how Excel does this: first the mouse shows the loading icon, then the saving occurs, then back to normal. No message, no UI feedback, and the save button is still enabled (even though Excel opens files with exclusive access and hence no external changes should occur). I think I will go for a similar approach, the only difference respect from now being the loading mouse icon.