Re: [ 1465615 ] Unsaved edits are lost when

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [ 1465615 ] Unsaved edits are lost when

Robert Manning

This issue has been unresolved for quite some time so it would be
great if you took some time to look into it.

See my responses below:

On Dec 28, 2007 12:10 PM, Alex Pivovarov <[hidden email]> wrote:

> Message body follows:
> Hi Rob
> About bug [ 1465615 ] Unsaved edits are lost when ....
> I think that main and second windows should work with files
> the same way as if I open two sessions (two main windows).
> 1. If I try to close secondary window I should be asked
> about save changes or not.
> 2. If I save changes in a secondary window implicitly it is
> my responsibility to control possible data overriding.
> (the same way as if I have two session and two main windows)

Indeed, that sounds like the most intuitive behavior.  I'm sure that
the original intent was for the main and secondary windows would work
the same way - as much as possible.  One exception being that closing
a secondary window shouldn't disconnect a session like main window
does; but closing a main window should cause secondary windows to
close.  This closing behavior is what the app currently does

> Don't you think that firstly user should be asked about
> saving  file and only after it asked if he/she wants to
> close session.
> In this case saving changes could be placed under the
> closing window event -- does not matter main or secondary.

Yes, I agree.  I suppose that I didn't see that case because I always
disable the "Confirm Session Close" dialog, but enable the "Prompt for
unsaved changes" dialog.  The sequence that you described makes sense,
especially when both dialogs are enabled.

> Later we could add more advanced analysis and avoid saving
> data in the file if the file was already opened in other
> windows (allow only save as).

Yes; ideally we would want to somehow let the user know that they've
re-opened the same script in a secondary window.  Maybe set background
yellow to indicate that it's read-only and prevent changes?  I'm not
sure that is the perfect solution to this edge case, but I am positive
that allowing two editors with changes to the same file is a recipe
for disaster, from a user's point of view.

> It could be nice to do advanced right now. But now two main
> window behavior (with possible file overriding) already
> works and nobody complain to it -- so why simply not to do
> the same for the main/secondary windows?

Once again, you are correct.  More than one session can open the same
file.  And a new FileManager is created for each new SQL panel.
Perhaps you could introduce a FileHistoryService with a factory method
that maintains a singleton instance of FileHistoryService?  Each new
FileManager could then get a reference to this singleton and tell it
when it opens/closes a file.  The FileHistoryService could indicate
somehow when opening whether or not the file is already currently
opened in a another FileManager. Asking the user to confirm whether or
not to continue opening the file (albeit in read-only mode) would be a
nice touch.

> If you think it is ok I could look at it next week.

That would be great.


This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Squirrel-sql-develop mailing list
[hidden email]