dummzeuch

The dxGetText installer available from SourceForge has been quite outdated for a while. Via this StackOverflow answer I got this link, where somebody actually went through the trouble to update the tools and create ... https://blog.dummzeuch.de/2018/12/02/using-dxgettext-on-windows-10/

And don't forget the resources spent on fixing that theming stuff, not just in the IDE but also in the IDE extensions. I spent several days just trying to fix things in GExperts that were broken due to introducing the theming bugs in theming bugfixes in theming And I am still not done. And GExperts doesn't even support theming itself, I don't want to consider the time it would take to actually support it (and I am definitely not going to spend that time).

(How do I delete a quote in the mobile interface? Backspace doesn't work.) OK, that's good. As long as the change does not introduce any new problems, I consider the case closed. Thanks for your contribution everybody.

A few weeks ago, Sue King contacted me because there was a problem with using dxGetText together with the Nexus DB components. For Unicode aware Delphi versions gnugettext.pas declares a function utf8decode which calls System.UTF8ToWideString. After replacing a call to utf8decode with UTF8ToUnicodeString the problem went away. Since I don’t want to break backwards compatibility with non Unicode Delphi versions I have now changed gnugettext.utf8decode to call UTF8ToUnicodeString instead of UTF8ToWideString. I can’t see any problem with this change but I am far from being an expert on Unicode related issues. So, if you find any problem with this change, please comment https://blog.dummzeuch.de/2019/03/09/gnugettext-pas-using-utf8tounicodestring-instead-of-utf8towidestring/

Utf8Decode existed as an RTL function in older versions (I just checked Delphi 6: It's in system.pas, line 17659). Only in Unicode aware Delphi versions was it marked as deprecated. The gnugettext.Utf8Decode function has already been enclosed in {$ifdef unicode} ... {$endif} since it was introduced in 2012.

I think there is an additional twist: The function gnugettext.Utf8Decode is being inlined, so there is one more possibility for code generation errors. (Took me a while to figure out why my break points in that function never worked.)

It is available since at least Delphi 2009. That's the version I tested with.

I suggested a solution to disable the interbase driver.

Have you tried deleting / renaming DBXInterBaseDriver180.bpl ?

committed. @Sue King could you please test if this has solved your issue?

OK, looking at it again, I still see no reason not to change gnugettext.Utf8Decode from calling System.Utf8ToWideString to System.UTF8ToUnicode. The svn blame function unfortunately does not give any insight because this code was already migrated from Berlios to SourceForge in 2012 and there is no further history available. So I'll commit that change.

On my computer it does not open the file in the IDE but in Notepad++. It simply opens the file with the associated application. And that's the problem: It cannot pass additional parameters for the line number to select, because it does not know which program is called and what to pass for it to jump to the correct line. The only way to do that would be to configure the program to call and which command line it needs. (From within GExperts in the IDE this works, because GExperts knows how to jump to a line number within the IDE.)

Hm, that's odd: if UNICODE is defined: gnugettext.Utf8Decode calls System.Utf8ToWideString which in turn calls System.Utf8Decode (in Delphi 10.3.1) I wonder what caused that Utf8Decode function to be added to gnugettext. Maybe there was a bug in early UNICODE aware Delphis? Or may it's simply because Utf8Decode was marked deprecated at some time. System.UTF8ToUnicodeString contains basically the same code as System.Utf8Decode with the exception that the Temp string is either a _WideStr or a UnicodeString. I'm too tired (I have been banging my had on the table all day to find a solution for a BDE problem under Window 10 😞. It seemed to work at last, when all of a sudden I got a priviliged instruction error 😞 ) to get my head around the implications. For now I see no reason why gnugettext.Utf8Decode should not call System.Utf8TUnicodeString rather than System.Utf8ToWideString, but I'll have to run some tests.

I have asked an admin to remove that post. I have no time now to actually check that race condition you mention.

I think we should not discuss my version in this thread as it is mainly about koskolos' implementation. As I said: I wrote that back when I read about lock free structures but never really tested it thoroughly and lost interest later. It would be too confusing to discuss both in the same thread.

It explicitly says "single reader", so that's a non issue. I agree with the rest of your post though.

A colleague of mine just cleaned his desk and cupboard. And by "cleaned" I don't mean "remove his stuff" but literally remove the dust accrued over several years. Talk about menial tasks...

fixed today in revision #2576

If you get the error “PrivateGXMenuActionManager is not nil upon creation” when starting your IDE, check the entries under HKCU\Software\Embarcadero\BDS\<version>\Expert There are most likely two entries for GExperts. Remove one and the error should go away. These entries come from The installer (GExperts=”path\to\dll”), because it always uses GExperts as the name for the entry. The Expert Manager (GExpertsXxx=”path\to\dll”), because it uses the name of the dll file for the entry. Yes, this is a bug. https://blog.dummzeuch.de/2019/03/01/gexperts-error-privategxmenuactionmanager-is-not-nil-upon-creation/

Fixed today in revision #2576

I want to get a list of interfaces registered in a Delphi 2007 application (with code from within that application) in order to check for possible duplicate GUIDs. There is a solution on GitHub which uses the System.RTTI unit, but unfortunately that unit is not available in Delphi 2007. Is it possible to do without? I also asked on StackOverflow: https://stackoverflow.com/q/54710667/49925

What exactly is an "unattended run" in this context?

The GExpertsRS103 entry is created by the GExperts Expert Manger (because it uses the DLL name as the entry). The GExperts entry is created by the installer.

Odd. I just used the latest GExperts to install it on my development computer and could start Delphi 10.3.1 without any problems. But of course that's different from what you have been doing: Installing GExperts first and then updating Delphi. I remember seeing this error before. If I now just could remember where and what was the cause... Could you please look into the registry under HKCU\Software\Embarcadero\BDS\20.0\Experts whether there are maybe muliple entries for GExperts?

Please note that there are known limitations with GExperts Grep Search on form files. A string will not be found if one of the following conditions is met: A string is split into several lines (in the form file) and the search string spans a line break (Bug #49). A string with special characters (e.g. Umlauts) is stored as 'bla'#nnn'blub' in the form file and the search string spans this special character (Bug #112).