(In reply to comment #0)
> Reproduction instructions:
>  soffice --norestore --nologo
>  Menu tools/macros/organize macros/LibreOffice Basic
>  navigate to My Macros / Standard / module 1 / Main (create if you need to)
>  Click on button "Edit"
>  Change some code, DO NOT SAVE
>  Close window
> 
> Expected result:
>  A dialog pops up, warning about unsaved changes, allowing the choose
> between Cancel, Save or Close without saving. Like with documents.
when you close what? the IDE?
Note: when you have modifications to the document ( any modifications not just to basic ) you can independently close the IDE without getting any nag. However when closing the document if there are any uncommitted changes you get told about that, but... that message is really nothing to do with the ide or basic ( more a side affect of the modifications the IDE has made )
What to do regarding changes to application basic is somewhat unclear, if you have open document(s) ( with modifications ) and you dismiss the ide should you only mention that there are unsaved 'application/shared/user' macros? should you ignore document macros? or should you just ignore it entirely ( like it does now ) Maybe you should defer till you try and shutdown the application ( because with the document behaviour you can open/close the IDE while the document is opened and your modified but as yet unsaved basic is available?
> 
> Actual result:
>  Changes are silently saved
Well that seems plain wrong, I would expect the changes to be missing if the application is exited without saving. However ( my own expectation ) is that prior to exiting any changes made in basic are available ( even if the IDE is opened/closed ) and regardless of whether the save button has been pressed

(In reply to comment #1)
> when you close what? the IDE?

When I close the _only_ LibreOffice window, which is the IDE,
and thereby close (exit) the _whole_ of LibreOffice.

> What to do regarding changes to application basic is somewhat unclear, if
> you have open document(s) ( with modifications ) and you dismiss the ide
> should you only mention that there are unsaved 'application/shared/user'
> macros? should you ignore document macros? or should you just ignore it
> entirely ( like it does now ) Maybe you should defer till you try and
> shutdown the application ( because with the document behaviour you can
> open/close the IDE while the document is opened and your modified but as yet
> unsaved basic is available?

I don't have a very strong opinion about these alternatives.
I do have the strong opinion that there *must* be a nag at *some* point.
IMO, "at Application shutdown" is too late. The user's cognitive link
to the Basic code is gone, it may be hours later without any visual cue
that something might be unsaved, ...

My preference would be that the nag for application basic should happen
when closing the IDE, because that's the equivalent of closing a document.

I'm nearly neutral about nag for document basic when closing the IDE,
and prefer no nag.

>> Actual result:
>>  Changes are silently saved

> Well that seems plain wrong, I would expect the changes to be missing if the
> application is exited without saving.

Yes, me too. But silently lost is also not good, it is a silent data loss.

> However ( my own expectation ) is that
> prior to exiting any changes made in basic are available ( even if the IDE
> is opened/closed ) and regardless of whether the save button has been pressed

By "available", you mean that the modified version of the code is executed?
My understanding is that this is the case: it is "available" as soon as it
is typed.

(In reply to comment #2)
> (In reply to comment #1)
> > when you close what? the IDE?
> 
> When I close the _only_ LibreOffice window, which is the IDE,
> and thereby close (exit) the _whole_ of LibreOffice.
> 
> > What to do regarding changes to application basic is somewhat unclear, if
> > you have open document(s) ( with modifications ) and you dismiss the ide
> > should you only mention that there are unsaved 'application/shared/user'
> > macros? should you ignore document macros? or should you just ignore it
> > entirely ( like it does now ) Maybe you should defer till you try and
> > shutdown the application ( because with the document behaviour you can
> > open/close the IDE while the document is opened and your modified but as yet
> > unsaved basic is available?
> 
> I don't have a very strong opinion about these alternatives.
you need to if you want something sensible
> I do have the strong opinion that there *must* be a nag at *some* point.
> IMO, "at Application shutdown" is too late. The user's cognitive link
> to the Basic code is gone,
But.. that's what already happens with a document where you can already  close the IDE ( or alternatively switch to application basic ) at any time ( and not get a nag )
> it may be hours later without any visual cue
ditto with documents ( and even you might even be saving some unintended basic change(s) ) 
> My preference would be that the nag for application basic should happen
> when closing the IDE, because that's the equivalent of closing a document.
If you mean closing the IDE ( when no documents exist ) then it is similar, if you mean closing the IDE normally then... e.g. consider you have changes to application basic but then switch the IDE to view some document basic ( and perhaps even have some other documents open ) and *then* close the IDE, do you nag then ( and only point to application basic having chaged? or enumerate and prompt for each document or... should you perhaps nag when you switch the IDE view from application to document. Either way I think it gets annoying/confusing for the user, there needs to be some reasonable and consistent behaviour but... I have no clue :-)
> 
> I'm nearly neutral about nag for document basic when closing the IDE,
> and prefer no nag.
> 
> >> Actual result:
> >>  Changes are silently saved
> 
> > Well that seems plain wrong, I would expect the changes to be missing if the
> > application is exited without saving.
> 
> Yes, me too. But silently lost is also not good, it is a silent data loss.
sure but this just a different facet of the same core issue
> 
> > However ( my own expectation ) is that
> > prior to exiting any changes made in basic are available ( even if the IDE
> > is opened/closed ) and regardless of whether the save button has been pressed
> 
> By "available", you mean that the modified version of the code is executed?
> My understanding is that this is the case: it is "available" as soon as it
> is typed.
By available I mean whenever you open/close/open the IDE, the application basic ( complete with any unsaved changes ) is what you get

(In reply to comment #3)
> (In reply to comment #2)
>> (In reply to comment #1)

>>> What to do regarding changes to application basic is somewhat unclear (...)

>> I do have the strong opinion that there *must* be a nag at *some* point.
>> IMO, "at Application shutdown" is too late. The user's cognitive link
>> to the Basic code is gone,

> But.. that's what already happens with a document where you can already 
> close the IDE ( or alternatively switch to application basic ) at any time (
> and not get a nag )

Yes, but there is still a window that shows the document, so there is a
continuous link. The basic code is not *shown*, but that's similar to a
change to an unused Writer document style: no effect on screen, but still
it is a change to the document and the document is on an existing window.

>> My preference would be that the nag for application basic should happen
>> when closing the IDE, because that's the equivalent of closing a document.

> If you mean closing the IDE ( when no documents exist ) then it is similar,
> if you mean closing the IDE normally then... e.g. consider you have changes
> to application basic but then switch the IDE to view some document basic (
> and perhaps even have some other documents open ) and *then* close the IDE,
> do you nag then

Yes.

> ( and only point to application basic having chaged? or
> enumerate and prompt for each document

Enumerate and prompt for each.

> or... should you perhaps nag when you
> switch the IDE view from application to document.

The Basic IDE has this "weakness" or let's say "difference to the rest
of LibreOffice" that it uses a unique window, and thus this window
switches one module to the other.

For better consistency, we could change the IDE to have a window
per opened module. By "window", I don't necessarily mean "full top-level
OS-level window", but it could be a "subwindow", that is a window that
is shown within the IDE top-level window.

But that's a bigger work. In the meantime, we have to (imperfectly)
map the concepts of the usual "one window per document unit" world
to the IDE's unique window.

It could make sense to nag for save when switching from one module
(or dialog) to another, by mapping that action to
 "close window, open new window"
in the one-window-per-unit world.
But IMO, this would be too impractical for the user.

> Either way I think it gets
> annoying/confusing for the user, there needs to be some reasonable and
> consistent behaviour but... I have no clue :-)

I think my preference is the most reasonable and consistent
that can be achieved with the current "IDE is exactly one window".

(In reply to comment #4)
> 
> Yes, but there is still a window that shows the document, so there is a
> continuous link. The basic code is not *shown*, but that's similar to a
> change to an unused Writer document style: no effect on screen, but still
> it is a change to the document and the document is on an existing window.
I don't buy that, you have no clue what change is in the document, just that there is *some* unsaved modification to the document model
> 
> >> My preference would be that the nag for application basic should happen
> >> when closing the IDE, because that's the equivalent of closing a document.
> 
> > If you mean closing the IDE ( when no documents exist ) then it is similar,
> > if you mean closing the IDE normally then... e.g. consider you have changes
> > to application basic but then switch the IDE to view some document basic (
> > and perhaps even have some other documents open ) and *then* close the IDE,
> > do you nag then
> 
> Yes.
> 
> > ( and only point to application basic having chaged? or
> > enumerate and prompt for each document
> 
> Enumerate and prompt for each.
As I think about it more IMO it would be more annoying to be prompted to save each document that has it's modified state set when dismissing the IDE ( if that is really what you are suggesting).
Ideally one should be prompted only if basic has been changed and also save from the IDE should just save/commit just the basic storage. I have no idea why that isn't the way it works or if there are practical reasons why it doesn't work that way
> 
> > or... should you perhaps nag when you
> > switch the IDE view from application to document.
> 
> The Basic IDE has this "weakness" or let's say "difference to the rest
> of LibreOffice" that it uses a unique window, and thus this window
> switches one module to the other.
you mean switching between library container(s) ( be that a document or some application area )
> 
> For better consistency, we could change the IDE to have a window
> per opened module. By "window", I don't necessarily mean "full top-level
> OS-level window", but it could be a "subwindow", that is a window that
> is shown within the IDE top-level window.
perhaps I don't understand exactly what you mean, I don't see how it makes a difference, you still could be closing the ide with multiple ( subwindows ) open
> 
> But that's a bigger work. In the meantime, we have to (imperfectly)
> map the concepts of the usual "one window per document unit" world
> to the IDE's unique window.
I think the main problem is the state of the basic in the longer living containers ( e.g. share/user ) that are active for the lifetime of the application, That is the one the doesn't map easily to raising a nag at a specific time.
> 
> It could make sense to nag for save when switching from one module
> (or dialog) to another, by mapping that action to
>  "close window, open new window"
> in the one-window-per-unit world.
> But IMO, this would be too impractical for the user.
> 
> > Either way I think it gets
> > annoying/confusing for the user, there needs to be some reasonable and
> > consistent behaviour but... I have no clue :-)
> 
> I think my preference is the most reasonable and consistent
> that can be achieved with the current "IDE is exactly one window".

I'm afraid I've lost track now exactly what your preference is, I don't have a problem with a nag dialog but as yet I don't fully see what nag ( and the content you would see ) under which circumstances you would be presented with for various scenarios of application and/or open document(s) with/without modified basic.

Another possibility in the mean time would be to disable the save button when an application container is selected in the IDE ( and preserve the behaviour where changes to basic are sticky for those containers ) at least that would be consistent

(In reply to comment #5)
> (In reply to comment #4)

>> Yes, but there is still a window that shows the document, so there is a
>> continuous link. The basic code is not *shown*, but that's similar to a
>> change to an unused Writer document style: no effect on screen, but still
>> it is a change to the document and the document is on an existing window.

> I don't buy that, you have no clue what change is in the document, just that
> there is *some* unsaved modification to the document model

No clue what change there is: that is correct, but that is nearly always the case,
even with changes to the document itself. The only exception I can think of is
Writer documents with "change tracking" enabled. In all other situations, there is
no clue what changed in the document, whether the changes are in Basic code or in
the "main" document itself.

Basically, my observation is equating the Basic IDE with a dialog of Writer or Calc.
E.g. if one opens a Calc window, and then goes to Tools / Options / LibreOffice Calc /
Calculate and then changes the choice of "Date" from 12/30/1899 to 01/01/1904", then
press OK. The document just had an "invisible" change. Same if I go to "Format / Page"
and change something there. In the mental model I propose, the Basic IDE serves the
same function as these dialogs.

>>>> My preference would be that the nag for application basic should happen
>>>> when closing the IDE, because that's the equivalent of closing a document.

>>> If you mean closing the IDE ( when no documents exist ) then it is similar,
>>> if you mean closing the IDE normally then... e.g. consider you have changes
>>> to application basic but then switch the IDE to view some document basic (
>>> and perhaps even have some other documents open ) and *then* close the IDE,
>>> do you nag then

>> Yes.

>>> ( and only point to application basic having chaged? or
>>> enumerate and prompt for each document

>> Enumerate and prompt for each.

> As I think about it more IMO it would be more annoying to be prompted to
> save each document that has it's modified state set when dismissing the IDE
> ( if that is really what you are suggesting).

No, sorry, I expressed myself incorrectly. What I meant is that there should
be one nag per non-document Basic module. E.g. if there are unsaved changes in
"My Macros/Standard/Module1" and in "My Macros/Standard/Foo" and in
"bar.odt/Standard/qux", then on closing the Basic IDE, there should be *two*
nags: one for "My Macros/Standard/Module1" and one for "My Macros/Standard/Foo",
but none for "bar.odt/Standard/qux".

If that is structurally hard/impossible with the way Basic code is organised
in LibreOffice, then one nag per library (attached to "My Macros" or to "LibreOffice macros")
or even a global nag for "My Macros" (if any pending change) and one global nag for
"LibreOffice macros" (if any pending change) would be OK.


> Ideally one should be prompted only if basic has been changed

Yes, obviously.

> and also save from the IDE should just save/commit just the basic storage.

OK, this is another proposition, namely

 * on closing the Basic IDE, there is one nag for each (changed module of each
   library of each) document with changed Basic, *and* one nag per (changed
   module of each library of each) "My Macros" and "LibreOffice macros".

 * in this nag (and when saving from Basic IDE in general), "save" saves only
   the Basic code, not the other changes in the document.

This scenario, taken as a whole, makes sense. Dunno if it can be implemented
reasonably easily.

>>> or... should you perhaps nag when you
>>> switch the IDE view from application to document.

>> The Basic IDE has this "weakness" or let's say "difference to the rest
>> of LibreOffice" that it uses a unique window, and thus this window
>> switches one module to the other.

> you mean switching between library container(s) ( be that a document or some
> application area )

There is a three-level structure:

 - level 1: document or "My Macros" or "LibreOffice Macros"
 - level 2: library, e.g. "Standard"
 - level 3: module, e.g. "Module1"

I wrote "level 3", but meant "level 2", yes. Because the IDE shows
the multiple level 3 containers (objects?) as tabs.

>> For better consistency, we could change the IDE to have a window
>> per opened module. By "window", I don't necessarily mean "full top-level
>> OS-level window", but it could be a "subwindow", that is a window that
>> is shown within the IDE top-level window.

> perhaps I don't understand exactly what you mean, I don't see how it makes a
> difference, you still could be closing the ide with multiple ( subwindows )
> open

Yes, but then you have a more clear mental model. E.g. you can close just one
subwindow, and then... what happens? You get (if unsaved changes) a nag for
just the module opened in that subwindow? Then *clearly* if you close the IDE
you should get a nag for *every* opened subwindow that has unsaved changes.

Another example of clearer mental model: if you are editing a module and
want to "switch" to another one, you can either:

 - close the subwindow for the first module and open a new window for the
   second module

 - just open a second subwindow for the second module

These are not the same operations, and it is "expected" that one does not
get the same "want to save?" nags in these two different operations.

But because the current IDE's approach makes it impossible to edit Library2/module2
without "removing" Library1/module1 from view, I think that nagging for save of module1
when switching to Library2 is too onerous.

Actually, now that I think of it, a working mental model for the current IDE is that
its unique window is "two level tabs". One level to choose a library (the "Current Library"
listbox widget), and then one level to choose the module (the tabs at bottom of the screen).
This maps to the more familiar "multiple (sub)windows" world by saying that as long as the
IDE is open, *all* modules of *all* libraries are opened (in their own subwindow). And then
it makes sense to get a nag (only) when closing the IDE (or the document container), because
that's when the "subwindow/tab" gets closed (disappears).

>> But that's a bigger work. In the meantime, we have to (imperfectly)
>> map the concepts of the usual "one window per document unit" world
>> to the IDE's unique window.

> I think the main problem is the state of the basic in the longer living
> containers ( e.g. share/user ) that are active for the lifetime of the
> application, That is the one the doesn't map easily to raising a nag at a
> specific time.

I see one specific time: when closing the IDE.

>> I think my preference is the most reasonable and consistent
>> that can be achieved with the current "IDE is exactly one window".

> I'm afraid I've lost track now exactly what your preference is, I don't have
> a problem with a nag dialog but as yet I don't fully see what nag ( and the
> content you would see ) under which circumstances you would be presented
> with for various scenarios of application and/or open document(s)
> with/without modified basic.

To close *this* bug without going into a big redesign of how the IDE works:

 * Basic in document: one nag on closing the document, if anything in the document
   changed (document itself or Basic code or both). This nag already exists.

 * Basic in application / user store: nag on closing the IDE. I would like to get
   one nag for each changed module, but one nag per library or failing that one nag
   for application and one nag for user would be OK. This nag is missing.

> Another possibility in the mean time would be to disable the save button
> when an application container is selected in the IDE ( and preserve the
> behaviour where changes to basic are sticky for those containers ) at least
> that would be consistent

Yes, that would be an acceptable mitigation, but then they *must* be written out
to disk "often", not only when closing the IDE or (worse!) when closing the whole
LibreOffice process. This would lead to data loss on crashes!

I don't like it much (because no way to say "throw away all changes I made since
last save", which is something I like to use) but would be working.

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > I'm afraid I've lost track now exactly what your preference is, I don't have
> > a problem with a nag dialog but as yet I don't fully see what nag ( and the
> > content you would see ) under which circumstances you would be presented
> > with for various scenarios of application and/or open document(s)
> > with/without modified basic.
> 
> To close *this* bug without going into a big redesign of how the IDE works:
> 
>  * Basic in document: one nag on closing the document, if anything in the
> document
>    changed (document itself or Basic code or both). This nag already exists.
> 
>  * Basic in application / user store: nag on closing the IDE. I would like
> to get
>    one nag for each changed module, but one nag per library or failing that
> one nag
>    for application and one nag for user would be OK. This nag is missing.
If may be only practical to provide a nag for 'Application' ( e.g. user & share ) iirc saving granularity is at the library container ( and I believe a single container is responsible for both user & share )
> > Another possibility in the mean time would be to disable the save button
> > when an application container is selected in the IDE ( and preserve the
> > behaviour where changes to basic are sticky for those containers ) at least
> > that would be consistent
> 
> Yes, that would be an acceptable mitigation, but then they *must* be written
> out
> to disk "often", not only when closing the IDE or (worse!) when closing the
> whole
> LibreOffice process. This would lead to data loss on crashes!
I suspect it is working as above. Although one would expect to lose data on a crash anyway :-/
> 
> I don't like it much (because no way to say "throw away all changes I made
> since
> last save", which is something I like to use) but would be working.
:-) yes, I understand

Dear Lionel Elie Mamane,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug