dummzeuch

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).

It's off by default. I'm not sure whether it is even possible to change that default.

If there are multiple declarations of the same type (or variable or const or function or procedure) in different units, Delphi takes the last one it finds: Unit a; [...] type TBla = integer; [...] Unit b; [...] type TBla = string; [...] Unit c; [...] uses a, b; var x: TBla; [...] Would mean that x is a string. So, when searching for the relevant declaration, one must start at the end of the uses list: Unit c; [...] uses a, b; var x: b.TBla; [...]

It would also have to start from the last unit in the uses clause and stop when it finds the first match.

In yesterday’s update of the Delphi Custom Container Pack to support Delphi 10.3 Rio I had broken it for older Delphi versions. It no longer compiled for Delphi 2005 to 10.2. This is now fixed. (Thanks @limelect for pointing out the problem.) https://blog.dummzeuch.de/2018/12/30/delphi-custom-container-pack-fixed-for-delphi-2005-to-10-2/

There is just the original rtf file by Sergey Orlik which is linked from the project page. But since I haven't changed anything in the actual functionality it should still be valid.

You can simply create one.

Prompted by a suggestion from Peter Aschbacher I just added a new feature to my Delphi Help Expert: You can now force it to use the default web browser instead of the Welcome Page for web URLS. https://blog.dummzeuch.de/2019/01/01/new-option-in-delphi-help-expert-to-open-in-web-browser/

I'm not complaining, just repeating what he told me.