Open UlrichSi opened 6 years ago
Or just disable edit mode for the 2nd +instances?
Hard to believe to be honest. I am going to try to reproduce.
What can happen: The same page is edited by two different instances. Then the last save win. Nothing we can do about that. It was discussed during implementation and we all agree to not spend any time on that.
Different pages however: should be no problem
@UlrichSi As expected, the working journal supports multiple instances using the same journal
On my tests, I opened the same journal in two different apps, adding one page on one and another page on the other. No problem was found.
Even better, text changes on Page2 with tool 2 were reflected immediately on tool 1 after opening page 2 in tool 1
I cannot reproduce the problem.
Of course, EDITING THE SAME PAGE in two different tools will result in loss of data. But well...
@msevestre: I checked again - you are right, "the last one wins" if I follow your protocol.
Thus, the issue I observed was most likely caused by the WJ behavior already discussed elsewhere: Since the WJ editor does not have an explicit SAVE button, another instance might override my additions by just closing its edit window, when apparently an automatic save is done.
We may want to display a warning if the same WJ page is opened by two instances at the same time. Or really set the second and following instances to read-only and let the user know?
Since the WJ editor does not have an explicit SAVE button, another instance might override my additions by just closing its edit window, when apparently an automatic save is done.
Sure. But why would you open the same page in two different instances? isn't the problem here simply between keyboard and chair? :)
Note that this was also an explicit requirement not to have to click on save every time to save the content. This behavior could be changed if there is a consensus that this is how it should work. e.g. No automatic save, navigating to next page or previous page will prompt for save if save button was not pressed. Closing the view will also prompt for save if it was not done. Old school but why not. @Yuri05 Thoughts?
At any rate, the issue is not as bad as initially described in my opinion and unless there is a strong opposition, I would not implement it in 7.4 as we have bigger fish to fry
Sure. But why would you open the same page in two different instances? isn't the problem here simply between keyboard and chair? :)
The reason to open it twice is that this is the only way to quickly flip between pages of a WJ. For example, copying or moving passages within the WJ is sometimes needed, or one likes to compare or reference another part of the WJ,
Personally, I prefer to have a distinct SAVE button to remain in control rather to have the software doing obscure things behind my back.
However, I agree with @msevestre that this issue is not that urgent. After all, there is always the option to change the workflow and use MS Office for documentation.
After all, there is always the option to change the workflow and use MS Office for documentation.
I concur completely. I'd like to know how many users are actually using the WJ feature. At the end of the day, I'd bet that most users are using word to submit their report. Why use a tool in between that will for sure mess up all the formatting is a real question for me.
And again. Adding the save button is not a problem. This will not prevent you from overwriting your own stuff if you start editing in multiple instances however.... So back to square one.
The unique advantage of the WJ functionality is that you can attach parts of the project to a page. However, with a few more steps one can save a PKML file or "freeze" a project file and enter a link into MS Office.
@UlrichSi Do we implement a save button then or let it as is?
Just leave it as it is for the time being. I can live with the way it is, so let's wait if anybody else cares about it.
If a working journal is opened by several instances of PK-Sim/MoBi, only the first instance appears to in a write-enabled status, thus saving any changes. All following instances appear to be in read-only status; any changes made here are discarded without giving notice to the user.
Since this behavior may confuse the user (who has not necessarily kept track of which instance was opened first), I suggest a clear read-only labeling of the WJ window.