dummzeuch

If you are maintaining a library, component or plugin for various Delphi versions you will sooner or later hit a point where it becomes necessary to have different code for some of them. Some examples are: The constants faTemporary and faSymlink are only declared in Delphi 2009 and later, so you have to declare them yourself for older versions. Some Open Tools API function have bugs in some versions so you have to implement a workaround. Some classes or functions have been added to later versions of the RTL so you need to implement them yourself for older versions, but you don’t want to use these implementations for newer versions The traditional way of masking code for some Delphi versions is using the VERxxx symbols which the compiler defines, where xxx is the compiler version multiplied by 10. Note that the compiler versions started with Turbo Pascal, not with ... https://blog.dummzeuch.de/2018/12/02/conditional-compilation-for-various-delphi-versions/

Your definition of "traditional" obviously is different from mine. Maybe I'm just older. In my blog post I actually continue: > An alternative is the {$IF } compiler directive which can test for arbitrary Boolean expressions [...] It was added to the Delphi compiler in Delphi 6, so it covers quite a few Delphi versions. <

Me neither! Just pay me enough(*1) and I will do that for you - for one hour per week. *1: Enough means that that one hour per week must be enough to live on.

Did you know that 86.64% of all statistics are made up? The remaining 53.42% have been tampered with. Seriously, is there any sense behind this number?

I just added a test for using gnugettext in a multithreaded environment: https://svn.code.sf.net/p/dxgettext/code/trunk/tests/MultithreadedResourceStringTest Could you please checkout this test and try to run it on your computer? If it's something that happens only there, maybe this simple test case might get some more information. There are two projects, one for Delphi 2007 and the other for Delphi 10.2. I haven't got Delphi 10.3 here to test, but loading and compiling the Delphi 10.2 project in Delphi 10.3 should work fine. Note that the project is meant to be run in the integrated debugger because in case of failure, the threads just raise an excpeption. These exceptions are only visible in the debugger.

Define "fail". For German language settings it returns a comma, which is probably correct in most cases. Fail means that it might improperly return '.' on English language settings. If I knew the correct language settings for the input, I wouldn't have to guess the decimal separator. Yes, I am aware of that (as I said in the original post). In that case it would not matter. I could simply use '.' or ',' to convert it to a number and would get the correct result for either.

Please file a bug report on SourceForge. And be more specific in it.

Because I don't know that it is an integer. I get a string that is supposed to be a number. I assume that the decimal separator is either a comma or a dot. I try to guess which one it is. One criterion: The decimal separator is only allowed once. There is none, as I already wrote in my original post:

Will also fail on '1.000.000'. (Yes, I have read the comment, but that case is not as rare that I would accept the function to fail on it.)

But you usually don't post credit card receipts on a sign post at a busy place. You just posted a picture of your signature on the internet ...

I started out with that approach, but: In '1.000.000' the decimal separator would definitely not be '.'. (or '1,000,000' it wouldn't be ',').

Ah, OK, I understand what you are getting at. Hm, I don't remember seeing any assembler code in gnugtetext.pas. And since it is a stand alone unit that uses only Delphi system units, I doubt that this could be the case. Even if it were the case, I would not know were to look. Also, IIRC you said, that you ran your test program in the debugger. This kind of bug should have triggered the debugger to stop. You didn't mention any such error, so I guess there isn't.

Possible. Since I have no idea what caused it, I can't really say. But as far as I know about how IDEFixPack works, it should not affect the compiled executables. Uninstall the IDEFixPack, compile your test program and test it again. Then you'll know.

SourceForge had a time with technical problems (not only with svn), and it took them quite a while to sort them, but they are now back to being reliable and fast. During that time I moved many of my open source projects to OSDN (which started off as a SourceForge clone). They are also quite good. Also, github offers svn access to git repositories. It works for simple cases. My most treasured feature of svn - externals - is not supported though. But of course these are mostly for open source projects. I would not use a cloud service for proprietary sources at all.

Have you and your coworkers got any experience with Git or Mercurial? If not, I stongly advise against those. They are distributed versioning systems and therefore very different from MSVSS (unless the latter has changed from when I used it) In addition to learn a new VCS you will also have to learn a new concept of VCS. SubVersion more closely resembles the way MSVSS works, so I would suggest using it. Unless of course you have got a need for a distributed VCS, you all already know how to use Git or you want to use Git for other reasons (e.g. it "is the VCS that everybody uses"). I agree with @haentschman: Use TortoiseXxx rather than the integrated IDE support, in this case TortoiseSVN.

Unfortunately not. It's the very basic (and buggy) docking support that was used in Delphi 7 and earlier. The new one is much better but sadly not part of the standard VCL. (I filed a bug report on that already.)

You can't delete a post at all. The way to go is to report it so an admin can delete it.

OK, I don't think I can do more without access to the sources. This is now down to guesswork. Have you tried to stop execution in the debugger when the program hangs on shutdown? There should either be an infinite loop or an infinite wait for an event, mutex or critical section. The call stack should give a hint.

There are two types of debug information, one is used for the internal debugger (set in Compiler Options), the other for the external /remote debugger (set in Linker Options). Are you sure that you have added the same kind of debug information to all projects? If you have added the debug info for the external debugger only to that one project, that would explain the difference in size.

As a test whether a bug in TMultiReadExclusiveWriteSynchronizer is to be blamed, I have just replaced it with the TMultiReadSingleWrite class from DWScript. Here is the code: https://download.dummzeuch.de/twm/gnugettext-pas-with-TMultiReadSingleWrite.zip Could you please download and try it? It's only active if the symbol dx_UseDWSMultiReadSigleWrite is defined (which I have done in the code linked above). If we believe Eric Grange (which I tend to do), it is also much faster, but that was with the implementation from 2013, so might no longer be true. Also, it is not reentrant. I have not checked whether that might be a problem with dxgettext.

RefCount should always be 0 if the class is not assigned to an interface variable, which it isn't. So that change basically means: if true then begin Result := MsgId; Exit; end; So, that's not a solution to the actual problem. Did you try to set a breakpoint in the finalization section and single step through it to find the position where it hangs? (Or maybe see that it doesn't hang there but somewhere else?) I looked at the code and can't find anything wrong with it. It does use various instances of TMultiReadExclusiveWriteSynchronizer which, if I remember correctly, was broken in several RTL versions. So using that class might not have been the best decision. But on the other hand, my memory might fail me and anyway those bugs should have been fixed long ago. Which Delphi version are we talking about? 10.1, as your profile suggests?

I just had a look at the download statistics of my dzEditorLineendsFix tool on SourceForge. Even 5 years after the Windows update that broke Delphi 2006 to 2010 there are several hundred downloads per month. https://blog.dummzeuch.de/2019/01/26/5-years-later-dzeditorlineendsfix-is-still-relevant/

Not in my installations. I turn that off whenever I get it.

I'm working on some project, a colleague calls and has a question about a different project. To be able to answer this question, I need to look at the source code of that project. So I open another instance of the IDE, to open that project without losing the current one. Sometimes this results in several instances running, not just two, because while looking up something another question came up. My record was 5. Yes, that's not a good way to stay concentrated and I try to deter them from interrupting. It just doesn't work very well...

I suspect that Nexus is also hooking LoadResString and this might conflict with the hooking gnugettext does. But since I don't use Nexus (and therefore don't have the source code), I can't verify this.