dummzeuch

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.

A plugin would probably not be the best solution because that would always prevent multiple instances of the IDE. I think pinning it to the taskbar is a simple solutin that should work. Otherwise I would write a program that checks if the IDE is running and if yes, brings it to the foreground, if no starts it. And then instead of starting the IDE start that program. (But basically that's the same as pinning the IDE to the taskbar.)

OK, I'm back home with a computer. What is the current status of the problem @Sue King ? Did you find the cause? Can you give me some more hints where to look? Edit: Yeah, right. I have got a computer, but it doesn't start. 😞 Why do these bloody things always break when you just want to get something done? (Because that's the only time you turn them on, obviously...)

That's unlikely to work, because many other units use the Windows unit, so the compiler will complain because it is newer than the one these units were compiled with. But I'll give it a try once I'm back at a computer with Delphi 10.3

There are multiple, overloaded declarations of this method. They differ in the number and/or types of parameters. The one you are calling has been marked as deprecated, which means that it will be removed in a future version. Check out the others, one of them is probably suitable to replace the one you are calling.