dummzeuch

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.

I wonder whether it's possible to make it work anyway...

You can't, unless there is a 3rd party plugin that allows it. I'm not aware of one.

I can't currently look at the code and I don't remember. I'll try to find out next week when I'm back from vacation.

If you have a version that works, and one that doesn't, I would take the list of changes to the file and, like in a binary search, try to find the revision were the problem starts to occur. That should be doable if the problem is reproducible.

Not just contracts. Don't underestimate the hassle of declaring taxes and associated stuff for what essentially would still be pocket money.

I'm not surprised given the many changes I have made to the code for accessing the editor buffer. Most of them were for the better, at least. 😉 It's very difficult to do regression tests for a tool like GExperts, given how many versions of the IDE it supports and that I am most of the time the only developer working on it. I don't catch many bugs when using GExperts because I rarely use many of the features. So I need good bug reports, especially ones containing steps to reproduce the problem reliably.

That sounds a lot like this bug: https://sourceforge.net/p/gexperts/bugs/79/ I think I know what the problem is but could not yet fix it (see my comments there).