setting tMenuItem.Caption with german umlauts and tab char fails

[Martin V]

Hello,

I use Menuitem.Caption := MyString in Windows. MyString has got german umlauts (ASCII > #127) and a Tab (#9) separator. Only simple text appears in the menu of my app, instead of Umlauts '?' appears, the tab character is not interpretated correctly.
(I need the Tab separator because of writing exotic key combinations which are not part of tMenuitem.Shortcut.)

A dirty hack using the old Windows API function ModifyMenu function works:
Windows.ModifyMenu(Menuitem.Parent.Handle, Menuitem.Command,  MF_STRING,Menuitem.Command,PChar(MyAnsiStringCaption));

The lcl function win32wsmenus.inc UpdateCaption uses the more current Windows API function SetMenuItemInfo which causes the problem. I wonder why these two Windows API functions handle the string different. The string is not converted by lcl before executing SetMenuItemInfo.

Is this a bug in LCL or do I need to convert the string before assigning to Menuitem.Caption?

The problem does not appear when using a lfm ressource. Then the string is handled correctly, both umlauts and tabs appear.

I do not know the behaviour on other OS.

[JuhaManninen]

Which version of Lazarus you have?
Please test with the latest SVN version. If it has the same problem then this is worth a bug report.

Regards,
Juha

[Martin V]

The Lazarus version is 0.9.28.2. I checked the bugtracker, nothing has been reported. If noone has any idea, I will try to make a proposal for a lcl fix. Anyway, I would be interested in Linux / Mac behaviour. Does these OS also accept for example MenuItem.Caption := '&Save'#9'Ctrl-S   ?

[Martin_fr]

Hello,

I use Menuitem.Caption := MyString in Windows. MyString has got german umlauts (ASCII > #127) and a Tab (#9) separator. Only simple text appears in the menu of my app, instead of Umlauts '?'

Without having tested anything, but you speak of ASCII > 127

If you give the LCL (and through the LCL to windows) any ASCII chars of that range, then that is supposed to fail.

The LCL works with UTF8 only.

If your code actually passes the utf8 sequence fur an umlaut to the LCL, and if that fails to show up correctly in the end-result => then there is a bug.

If you type the char directly into your source, using the IDE as editor, then please check the encoding of your file (pop-up-menu => file-settings => encoding)

It must be utf8.

if you use #162 (or whatever value) then that is wrong, utf8 umlaut has multiply bytes.

[JuhaManninen]

Hi,

I am also confused with the encodings.
However, this works under Linux using SVN Lazarus:

  MenuItem3.Caption := '&Open äöåÅÄÖ'#9'Ctrl-O';
  MenuItem4.Caption := '&Save'#9'Ctrl-S';

äöåÅÄÖ are shown correctly.
Ctrl-O and Ctrl-S get nicely aligned due to the TAB char. I didn't know that feature.

Please test again with the latest version. There has been some work on char encodings.

Juha

[Martin V]

The problem is more general: also tLabel.Caption and other Components have got the problem. I tried the current 0.9.28.3, no effect. Should I try the current 0.9.29?

[JuhaManninen]

I tried the current 0.9.28.3, no effect. Should I try the current 0.9.29?

Yes, testing the latest version is always a good idea when finding and reporting bugs.

Juha

[Martin V]

Meanwhile, I compiled my program on Ubuntu Linux and on MacosX and updated all Lazarus installations via daily build.

On Linux, the menu entries with german umlauts (ÄÖÜäöüß) are completely not shown (an empty area without text) if I simply write:

Code: [Select]

MenuItem.Caption := 'Text with umlauts';
In Windows, the text appears with ? instead of umlauts.

If I write

Code: [Select]

MenuItem.Caption := AnsiToUTF8('Text with umlauts');
the text in Linux and MacosX appears with ? instead of umlauts and in Windows, the output is OK.

Then I studied the formatting problem. I want to have menu entries with right-orientated commands, e.g.


Open      Alt-F3
Save          F2


In Windows.ModifyMenu, the tab char generates this break, but not in Windows.SetMenuItemInfo which is used by Lazarus. Linux and MacosX also fails with tab char (but perhaps there's another char code). If I use Menuitem.Shortcut, the output is OK in all OS, but I want to generate this output manually via Menuitem.Caption.
Windows Menuitem.Caption also fails if the distances differ more than aprox. 8 chars.

I have even debugged the LCL code to understand the Caption Shortcut mechanism, but did not managed it. Any ideas?

Martin

[JuhaManninen]

I don't know about Mac but on OpenSuse 11.2 Linux it works well. Tested with both GTK2 and QT bindings. GTK2 version doesn't align the strings after TAB correctly but QT version does.

I guess you have an old Ubuntu + Gnome + GTK2.
Please update or switch to OpenSuse + KDE. :-)

Juha

[Martin V]

I have got the current Ubuntu 10.04 installed.

I want to publish my program, so it is no solution to move to an OS where the problem does not exist.

Martin

[JuhaManninen]

I have got the current Ubuntu 10.04 installed.

That is the latest one, isn't it?
You should make a bug report with a complete demo project to reproduce the problem.
I don't have more ideas.

Juha

[Martin V]

Hello again,

the Umlaut problem seems to be fixed in the daily snapshot version since June-14-2010. On Win32 and Ubuntu Linux, a simple

Code: [Select]

Menuitem.Caption := 'text with umlaut"
without ansi/utf8 conversion works fine, and of course any additional conversion will fail. I have not tested the latest MacosX Lazarus version yet, but I assume that it will work, too.  Otherwise I will write a bug report.

The tab problem still exists, I write a bug report now.

Martin

[JuhaManninen]

the Umlaut problem seems to be fixed in the daily snapshot version since June-14-2010.

It worked for me already at May 29 (see my message earlier). I would still guess the reason was somewhere else in your system.
Anyway, now we both get the same results and that is more important.

Juha

[Martin V]

I have realized now that the problem is the source file conversion from ANSI to UTF8. In the Lazarus IDE Tools - Convert encoding correctly shows the encoding of the files, but the conversion seems to fail. I have converted my source files with an external conversion tool and now all works fine.

In the IDE, I would prefer that the editor makes a proposal to convert the file when loading the very first time.

Martin