Issue 25914

After further testing I find that using the "Edit Autotext" in a writer seems 
to fix something so that the API can access the autotext entries.

 Joel

SW->Joel: I could reproduce this with my OOo1.1 only if I renamed the
Autotext-file while the office ran and then executed the mentioned sample. If I
changed the filename while the office wasn't up all works fine. 
AFAIK the list auf available autotexts is gained when the someone tries to use
autotexts for the first time, so lets say you had 
a.bau
b.bau
c.bau
as the office started and since they have been used sometime, this is the list
of files that will be parsed. If you now rename b.bau to b_2.bau, opening the
file b.bau will fail what raises a RuntimeException.

For me this looks like the expected behaviour and not like a bug.

I would expect the API to behave the same as the application, or at least 
provide a method to refresh the list.  Clearly writer is refreshing it's list 
of AutoText entries as I do not get an error message when I open the AutoText 
entries via writer.

In unoatxt.cxx there is the comment 

// TODO: think about if we should pass "true" here
// The difference would be that when the next modification is made to this 
instance here, then
// we would be forced to open the document again, instead of working on our 
current copy.
// This means that we would reflect any changes which were done to the AutoText 
by foreign instances
// in the meantime

Please consider at least adding a method to force a reload/revalidate of the 
cache.

Thanks

SW->Joel: mmmh, the cited comment is from the
SwXAutoTextEntry::XAutoTextEntry::applyTo() and the issue you stated first was
related to SwXAutoTextGroup::XNameAccess::getElementNames() and
SwXAutoTextContainer::XNameAccess::getElementNames() respectively. So I don't
see the relation between this addition and the original issue :-)
The problem I have with this issue is that I don't see a benefit in adding an
additional Interface to the two containers to catch the rare case that the files
on disc change their names while the office runs with refreshing the container
instead of throwing a RuntimeException.
Can you describe a scenario where one will stumble over this while using the API
or is it just a 'hypothetic' issue ?

The heart of the issue is when there is a mis-match between the cache and the 
backing-store, which should be used.  One can 1) ignore the mis-match; 2) 
reload the cache from the store; 3) throw an error.  I pointed to the code 
section to show that one of your developers thought that rebuilding the cache 
might be the right thing to do, and that I wasn't completely crazy to suggest 
the some thing.  I wouldn't mind throwing an exception if it had actually told 
me what the problems was.  Throwing a "something went wrong someplace" 
exception is not very helpful.

I am working on an Java application that uses writer as part of a larger 
document generation/management system.  Part of the system includes an AutoText 
group that is available only when the doc management system is running.  The 
AutoText file is stored in the database and fetched to the user's work area 
when a document (also stored in a database) is fetched for editing.  Since the 
AutoText file can be edited and updated at any time by an authorized user I 
need to be able to refresh the AutoText on every document load.  And while the 
AutoText entries are (in my opion) correctly refreshed for the user using 
writer, I cannot access the entries from the API.  I had hoped to use document 
fragments in AutoText to populate the document based on values in the 
database.  For example, for a document of type 'A' for a customer of type 'B' 
we need paragraphs 'Foo', 'Bar', and table 'Blah'.  One advantage of using 
AutoText is that the user can also insert a 'Foo' paragraph if it is needed.

SW->TL: I suppose the 'autoupdate' on each container access has been avoided
because of performance reason and since it is most likely not needed during
'normal' access of these containers, I'd say adding the interfrace
css.util.XRefreshable optional to these containers could make the 'ui-like'
behaviour available for API-users too.

SW: changed state

Should this Issue be 'New' and resolved as WONTFIX?...

This Issue has been marked as 'Invalid' and not updated in 1yr+ ... any update
on where this should be going?

Many thanks,
Andrew

Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~

.