search

fernandreu / office-ribbonx-editor

An overhauled fork of the original Custom UI Editor for Microsoft Office, built with WPF
MIT License
528 stars 104 forks source link

Editor Closes Unexpectedly #67

Closed JonPeltier closed 5 years ago

JonPeltier commented 5 years ago

When I finish editing the custom UI of a document and close that document, the entire Editor application closes, rather than staying open with no documents loaded.

fernandreu commented 5 years ago

This is probably a duplicate of #57, which is fixed in the latest development build. Could you try that version and see if it works as expected?

Otherwise, if this happens because of a crash, the most recent versions of the tool should hopefully give you an error message when something like this occurs, with some informative text that you can paste here for me to debug.

celiasja commented 5 years ago

Hi, Jon. I had that same issue. In my case, I got it solved when I moved my files out of Dropbox where I was saving them.

On Wed., Oct. 30, 2019, 13:27 Fernando Andreu, notifications@github.com wrote:

This is probably a duplicate of #57 https://github.com/fernandreu/office-ribbonx-editor/issues/57, which is fixed in the latest development build https://dev.azure.com/fernandreu-public/OfficeRibbonXEditor/_build/results?buildId=466&view=artifacts. Could you try that version and see if it works as expected?

Otherwise, if this happens because of a crash, the most recent versions of the tool should hopefully give you an error message when something like this occurs, with some informative text that you can paste here for me to debug.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fernandreu/office-ribbonx-editor/issues/67?email_source=notifications&email_token=ANOUTSIMFN7L2IWWXJPJ6RTQRG7YHA5CNFSM4JG2RT4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECVCQVY#issuecomment-548022359, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANOUTSL2QRK4APWRQ6BBAJ3QRG7YHANCNFSM4JG2RT4A .

JonPeltier commented 5 years ago

I use Dropbox for some of my work, but not the add-in I was working on when I finally decided to report the issue.

I installed the 1.5.1.466 dev version and the unexpected closing of the application stopped. However, with this version I could not see the customUI xml code in the code window, though it was listed in the treeview. The icons I'd inserted also were visible in the treeview. Just to make sure, I closed the add-in and opened it in Excel; the buttons were present on the ribbon, so the xml must still be intact. The code was also visible when opened in 1.5.1.418.

I'll revert to the 1.5.1.418 production version.

fernandreu commented 5 years ago

Yes, now the editor is multi-tab and you have to double-click a file (or right click -> open) to show it on the right side. I thought this would be a bit more intuitive, as that is how the majority of multi-tab programs that I know of work.

With this, tabs won't start opening unintentionally when navigating through the treeview. This was reasonably fine in the previous single-editor layout because you would eventually open the file you were interested in, and none of the intermediate files selected would be shown. However, if it worked like this now, you might end up with tabs open that you are not really interested in editing.

Once I make an official release (after I polish a few more things) I will put some notes about this to try to make it as clear as possible.

At some point, I might do something similar to what Visual Studio Code does:

JonPeltier commented 5 years ago

Okay, thanks, the need to double click was not obvious since it wasn't necessary before, but I can get used to it.

Issues I had:

When only one tab is open, but several files are listed in the treeview, the tab label "customUI.xml" is not sufficient to identify which file's xml is being viewed (I know the active one is highlighted in the treeview, but my eyes are getting old). The filename should appear in the tab label when there are multiple files listed, even if only one is open.

I can have a file listed multiple times in the treeview: the program doesn't check if the file is already in the treeview. This seems to be wrong.

Good job overall, by the way.

fernandreu commented 5 years ago

Thanks for the feedback!

Good point about the tab names. There are checks in place so that, if several tabs are about to have the same name, the name of the parent element in the treeview is added to it. However, checking for conflicts in the treeview instead as you say makes more sense, so I will change that. This is again something I originally implemented based on how an IDE would act, but the scenario is a bit different here:

The possibility of opening the same file multiple times is something I was already aware of. It isn't exactly wrong, but has little practical use to be fair. A few examples:

I will probably add a check and, if you are about to open the same file, show you a yes/no warning message that still allows you to proceed opening the file if you want to (just in case somebody really needs this "feature").

JonPeltier commented 5 years ago

If I have the same file open twice, and I save (not save as) changes to one, then save (not save as) different changes to the other, which changes are saved? This could be dangerous.

fernandreu commented 5 years ago

The changes for which you clicked Save last will be saved. Agree it can be quite dangerous, which is why I will include a warning message.