Issue 95320 - Inconsistent labeling of unsaved documents
Summary: Inconsistent labeling of unsaved documents
Status: RESOLVED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 4.1.13
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needmoreinfo, oooqa
Depends on:
Blocks:
 
Reported: 2008-10-22 15:57 UTC by Stefan Weigel
Modified: 2022-07-21 10:56 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.12
Developer Difficulty: ---


Attachments
screenshot showing inconsistency between labelling of unsaved documents (88.04 KB, image/png)
2008-10-22 16:01 UTC, Stefan Weigel
no flags Details
one other effect shown in screenshot (109.68 KB, image/png)
2008-10-22 17:43 UTC, Rainer Bielefeld
no flags Details
Screenshot mentioned above (15.13 KB, image/png)
2009-11-23 07:35 UTC, Stefan Weigel
no flags Details
Examples of inconsistent labelling (669.47 KB, image/jpeg)
2020-08-05 16:56 UTC, Czesław Wolański
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Stefan Weigel 2008-10-22 15:57:57 UTC
The labelling of unsaved documents in OOo 3.0 has changed from "Untitled1" to
"Untitled 1" (a blank character has been added). However this change has not
been made consistently in every place, where these labels appear.

For example, the title of the document´s properties (Select File|Properties...)
still shows the old type of label, without the blank character.

More serious, the title of the printing job, that OOo passes to the system, when
printing an unsaved document, also differs from the new caption of unsaved
documents. Please have a look at the screenshot.

This difference is *not* a cosmetic matter, but a severe problem for automation
and integration of OOo in custom solutions. In fact, these solutions are broken,
if they try to identify a printing job and try to relate it to an OOo document.
For example, the OOo integration of AVM Fritz!Fax is subject to this matter.
Comment 1 Stefan Weigel 2008-10-22 16:01:09 UTC
Created attachment 57388 [details]
screenshot showing inconsistency between labelling of unsaved documents
Comment 2 Stefan Weigel 2008-10-22 16:05:36 UTC
@AS, please have a look.
Comment 3 Rainer Bielefeld 2008-10-22 17:40:05 UTC
It's not only the old label type, it's just another name! Properties of (German)
new document "Unbenannt 3" will show "Unbenannt1" as file name. Pls. see
additional screenshots.

@sweigel:
Pls. specify your OS and Platform, this bug might be OS-specific.
Comment 4 Rainer Bielefeld 2008-10-22 17:41:22 UTC
Forgot to mention: I checked with "Ooo 3.0.0 RC3 Multilingual version German UI
WIN XP: [OOO300m8 (Build9357)]" and can confirm the reported effect.
Comment 5 Rainer Bielefeld 2008-10-22 17:43:57 UTC
Created attachment 57390 [details]
one other effect shown in screenshot
Comment 6 Stefan Weigel 2008-10-22 20:26:21 UTC
Resetting OS from "Winsows XP" to "All".

Found this Bug with OO0 3.0 stable (OOO300m9) on
 - Windows 2000 SP4
 - Windows XP SP2
 - Ubuntu Linux 7.10
Comment 7 Stefan Weigel 2008-10-22 20:32:32 UTC
@rainerbielefeld: I cannot reproduce "Unbennant 3" --> "Unbenannt1". How did you
do that?
Comment 8 Rainer Bielefeld 2008-10-23 05:39:56 UTC
Indeed, currently I can only reproduce the bug from your report. I will do
several further tests and try to find out how the "Unbenannt 3" --> "Unbenannt1"
problem can be reproduced.
Comment 9 andreas.schluens 2008-10-23 11:52:37 UTC
Title shown inside title bar was never real thought to be used for printing ...
anyway ... somewhere reused it this way and now it's broken because framework
uses a complete new title bar (!) implementation.
Comment 10 Mathias_Bauer 2009-05-13 15:05:06 UTC
It seems that the insonsistency is caused by still using the old sfx based
methods. We must find the code using them and rework it to use the framework
based implementation (API at the model). 
Comment 11 Stefan Weigel 2009-11-23 07:34:18 UTC
Please try this:

(1) Open a new document (text or spreadsheet)
(2) In the toolbar click "Page Preview" several times and watch the title of the
window.

You will see the the title of the window go like this:
  Untitled 1
  Untitled 1 : 2
  Untitled 1
  Untitled 1 : 3
  Untitled 1 : 3
  Untitled 1 : 4
  Untitled 1 : 4
  Untitled 1 : 5
and so on.

Note: There is only one window for this document any time. But the caption
displays as if there were multiple windows of the same document.

Pleas also have a look at the following screenshot.
Comment 12 Stefan Weigel 2009-11-23 07:35:04 UTC
Created attachment 66271 [details]
Screenshot mentioned above
Comment 13 Mathias_Bauer 2011-02-10 17:33:30 UTC
I don't think that this issue deserves the keyword "regression".
The naming of unsaved documents always was broken to some degree. So it now just
is buggy in a different way. :-)
Comment 14 Marcus 2017-05-20 10:47:36 UTC
Reset assigne to the default "issues@openoffice.apache.org".
Comment 15 Czesław Wolański 2020-08-05 16:54:56 UTC
The current state of affairs (August 2020): issue still present.

The attached image file provides few examples
(Win 7, 64-bit, Home Premium; AOO 4.1.7 and AOO 4.2.0-dev).

Another instance (Navigator in Writer and Calc) is described in Issue 128400.
Comment 16 Czesław Wolański 2020-08-05 16:56:44 UTC
Created attachment 86973 [details]
Examples of inconsistent labelling
Comment 17 Dick Groskamp 2021-05-21 09:29:46 UTC
String seems to be originating from the variable STR_NONAME
Source in KID_localize.sdf:
sfx2	source\appl\app.src	0	string	STR_NONAME				0	kid	plblxp‖Untitled

Found references to SetTitle and GetTitle in file:
/trunk/main/sfx2/source/doc/objmisc.cxx 


Line 809 : void SfxObjectShell::SetTitle
Line 879 : String SfxObjectShell::GetTitle

Seems to originate from these lines:
833  	// wird 'unbenannt#' als Titel gesetzt
834  	String aNoName(SfxResId(STR_NONAME));
835  	if ( rTitle.Match(aNoName) <= aNoName.Len() )
_______________

Since I'm not at all a developer and don't know anything about C++ I will not touch the code, but if someone is interested: 
this is possibly where you might want to start looking
Comment 18 Matthias Seidel 2022-05-04 18:12:17 UTC
This should be fixed now in trunk (#75e50e85) and AOO42X (#4453b43)

Can someone confirm, please?

BTW:
Comment 11 and 12 show a different bug. Feel free to open another ticket for it.
Comment 19 Matthias Seidel 2022-05-15 11:35:59 UTC
I have tested now with the latest builds on all branches and did not find any occurrence anymore.