Recent changes to bugs

#156 TGnuGettextInstance.ngettext broken if SearchAllDomains is set to True

raller09 — Fri, 20 Jun 2025 06:47:10 -0000

Hi,

please see https://sourceforge.net/p/dxgettext/code/187/

Thank you

#157 RetranslateComponent will get the ListBox ListItem lose it changed such Tag, TagString...

wqmeng — Sun, 19 Jan 2025 15:11:13 -0000

Here is a solution of the matter.

https://github.com/landrix/Gettext-for-Delphi/issues/2

Thank you.

RetranslateComponent will get the ListBox ListItem lose it changed such Tag, TagString...

wqmeng — Sun, 19 Jan 2025 08:24:17 -0000

Hello,

When I use the RetranslateComponent, I find that the Component such as TComboBox, if I store something to the TComboBox ListItem Tag property, it will get detelted after Translate, The matter seems is the TComboBox is translated as a TStringList and then assgin the TStringList.Text to the TComboBox, which will delete all the old listitems and then create new listitems by the new Text value. Of cause the Tag values stored to the old listitems will be deleted too.

Also this will cause the TComboBox.ItemIndex value changed too, It will invoke a TComboBox.OnChange event too.

So that we need to translate the ListItems of the TComboBox, TListBox, TListView ... one by one instead of Translate the Text of them? In this cause, the old listitems will keep and everything of them will not get changed.

Thank you.

TGnuGettextInstance.ngettext broken if SearchAllDomains is set to True

Olivier Sannier — Thu, 09 Dec 2021 15:18:18 -0000

When SearchAllDomains was introduced the patch code suggested to change TGnuGettextInstance.ngettext like this:

  domain := curmsgdomain;
  domainIndex := -1;
  repeat
    Result := dngettext(domain, singular, plural, Number);
    Inc(domainIndex);
    if domainIndex < domainlist.Count then
      domain := domainlist[domainIndex];
  until not SearchAllDomains or ((Result <> singular) and (Result <> plural)) or (domainIndex >= domainlist.Count);

Upon inclusion, it has been rewritten to use a while loop like this:

  Result := dngettext(curmsgdomain, singular, plural, Number);
  if SearchAllDomains then begin
    domainIndex := 0;
    while (Result <> singular) and (Result <> plural) and (domainIndex < domainlist.count) do begin
      domain := domainlist[domainIndex];
      Result := dngettext(domain, singular, plural, Number);
      Inc(domainIndex);
    end;
  end;

In doing so, the condition for the loop should have been completely inverted but the tests on Result were left as is.
This results in the fact that a valid translation found by the initial call is immediately overwritten by the call to dngettext in the loop.
The loop condition should read like this:

    while ((Result = singular) or (Result = plural)) and (domainIndex < domainlist.count) do begin

Note how the tests on result have been inverted while still being grouped together.

With this, I now have the proper translation being returned.

Locale selection on Windows8+ from new WinAPI

OCTAGRAM — Sun, 06 Jun 2021 02:27:32 -0000

Windows 8 introduced a list of locales in the settings, as opposed to single language, like it was before. The Windows settings page tells that applications pick the first available locale from the list. However, applications using the outdated GetLocaleInfoW WinAPI get something else, something ridiculous, something that is adjusted via well hidden setting "Codepage for non-Unicode programs", which I had set up to be ANSI=UTF-8 mode long ago, so I had no idea I should ever be visiting it again.

In practice, as seen on screenshot, I have set up locale priority RU, EN, CN. I have set up Windows system GUI to be Russian one. And most of applications were in Russian. But some ones, like Wireshark and HeidiSQL were picking the least preferred locale, the Chinese one, in my case. Now I understand that it can also be a locale not from the list at all, a completely different locale, if somebody changed "Codepage for non-Unicode programs" and forgot about it, since we almost get rid of non-Unicode programs nowadays.

I propose using the new Windows.System.UserProfile.GlobalizationPreferences.Languages WinAPI. It is returning what is really a real list, and it is possible to pick a locale from it according to Windows settings label, the first supported one.

Maybe not the first one! Why not. If somebody has a list of FR, DE, then program can pick DE, as opposed to undesired EN, not even on the list, like gettext does now, when only aware of single preferred locale.

#153 Integer overflow in Proxify

Ivan Johansen — Sat, 31 Oct 2020 23:43:55 -0000

Unfortunately I am not able to step through pas files when compiling for 64-bit but only when compiling for 32-bit.

However it looks like the problem occur at this line in THookedObjects.Proxify(obj:TObject):
size:=NativeUInt(objClassData.ClassName)-NativeUInt(objClassData)+hookedClassNameLength+2;

I can see that it calculates 0x0000000000E3BC16 - 0x0000000001208360, which result in a negative value and it throws an EIntOverflow exception.

There is a comment above the code:
// According to Allen Bauer, we know that the ClassName is stored right after the
// virtual method pointers.

This doesn't seem to be the case for 64-bit on C++ Builder XE6. It looks like ClassName is stored at a completely different place.

NB. Thanks for trying to fix this. I am glad that someone is still working on dxgettext.

#150 Cannot compile ggassemble.exe - engine.PrepareFileList needs directory

Thomas Mueller — Fri, 30 Oct 2020 16:56:33 -0000

actually the fix was to pass 'locale'+PathDelim

fixed in revision #135

(unfortunately I can't close tickets here)

#153 Integer overflow in Proxify

Thomas Mueller — Fri, 30 Oct 2020 16:48:42 -0000

That's probably because you are using different compiler switches for Win32 and Win64.

Could you please provide the line number where the exception occurs? I don't have C++ Builder available for testing, but knowning the line number might enable me to spot the problem anyway.

#154 Errors when compiling on C++ Builder

Thomas Mueller — Fri, 30 Oct 2020 16:19:21 -0000

propsed fix applied in revision #134

(unfortunately I can't close this ticket, I only have write access to the sources but no admin rights to the project)

Errors when compiling on C++ Builder

Ivan Johansen — Mon, 03 Aug 2020 20:10:55 -0000

I am using gnugettext.pas from revision 132.
I am using C++ Builder XE6.

I get the following errors when including gnugettext.hpp:

[bcc64 Error] GnuGetText.hpp(353): expected unqualified-id
[bcc64 Error] GnuGetText.hpp(354): expected unqualified-id

The reason is that LOCALE_SISO639LANGNAME and LOCALE_SISO3166CTRYNAME defined as const in the interface section of gnugettext.pas are already defined in winnls.h.

The problem can be solved by adding this to gnugettext.pas:

{$EXTERNALSYM LOCALE_SISO639LANGNAME}
{$EXTERNALSYM LOCALE_SISO3166CTRYNAME}