dummzeuch

... which is kind of the definition of "cooperative".

You're probably right. My experience described above was with Windows 2000. I don't think I ever used Windows 95, at least not for software development.

From your link: (emphasis mine) So that would mean Windows 95 had preemptive multitasking for 32 bit programs. I'm not sure though, I never really used it. Windows 3.x used cooperative multitasking for Windows programs, but preemptive multitasking for DOS programs. Of that I am sure because I used and programmed for it.

Hm, yes. Good thing I also mentioned NT 4 then.

Apart from some tests and upgrading my IDE plugins I haven't used Delphi 11 much yet. I'm currently on Delphi 10.2 and 2007 for work. Given the state of 10.3 and 10.4 I doubt that I ever will move on to these versions, I use them only for GExperts maintenance. And given all the "fun" I still have with trying to iron out the display problems in GExperts on Delphi 11, I guess I won't switch to Delphi 11 either. But time will tell.

Sorry, I can't read the mind of the cnpack developers. I was just trying to come up with a reason why somebody went to the trouble of implementing this. It might also be ancient, maybe to address something in Windows 95 or NT4 and Delphi 3, who knows? Which reminds me of something: In the olden days, when a CPU only had one core, before hyperthreading and when computers with more than one CPU were very expensive, I happened to get my hands on a dual CPU computer. I found several bugs in our Delphi programs the never occurred on other machines. Basically these were race conditions that could only happen if code was really executed in parallel, not simply multi tasked on a single CPU.

Regarding specs: Windows 10 seems to have some very efficient caching algorithm which means that given enough RAM it doesn't really matter whether your IDE or your Sources are on a hard disk or an SSD. An SSD mostly affects the boot time and the first start of a program / first loading of a file. (As said above: Given enough RAM. As the saying goes: RAM can be only be replaced with more RAM.) On RAM constricted systems, the effect of an SSD might be more significant. At least that's my impression, I haven't measured it.

I can only imagine that this might be useful for debugging some particular IDE or IDE plugin bugs/oddities. Nothing you should use for day to day work.

Has anybody filed a bug report on this yet? If nothing else, there should be a comment explaining why inherited Destroy isn't called.

Something just triggered the word "namespaces". I remember now that when discussing this topic on G+ there was the hope of splitting code of a namespace into multiple units. Unfortunately I don't remember if anything ever was implemented for this.

Thanks for your hints. Unfortunately it will take a while for me to review and possibly integrate them. I'm just back from vacation and fairly busy at the moment. Also, the official dxgettext and the fork in the JCL have by now diverged so much that it is difficult to understand the effects of changes to one of them for the other.

I would possibly have been interested, but its the wrong programming language (I don't do any C++) and wrong country for me (BREXIT is a gift that keeps giving ...)

Unfortunately there are two problems with dxgettext: Maintenance is basically nonexistent (apart from the odd fix I apply and my time is very limited). The original maintainer Lars B. Dybdahl hasn't committed any changes for years (the last log entry that from somebody else but me was in 2014) It only works for Windows, and there probably only for 32 bit VCL (I haven't tested 64 bit or FMX, but since it installs some hooks, it's unlikely to work without changes.) Regarding PoEdit: I prefer using Lars' tool "Gorm" nowadays, but that's because I have the source code. 😉

While I agree on having the new Indy sources in the repo as svn:external/submodule, I think leaving the original library in the search path (or even on the hard disk) may be dangerous. I have spent countless hours hunting for bugs that eventually turned out where caused by compiling the wrong sources / linking the wrong dcus. This can't happen if you delete them.

I improved the code checking and reading the cache files. It no longer uses TStringList.LoadFromFile but reads the whole file into a buffer and converts it. But that change is really old actually.

It doesn't happen here, so something must be different. And since I fixed it for older Delphi versions it is most likely caused by the changes I made to support high DPI.

That was my guess, but unfortunately that's not nearly sufficient: What are your monitor(s) resolution and DPI? Which is the primary monitor and which is the one the IDE is on and which is the one with the Uses Clause Manager window?

You named your topic ... Please write to Embarcadero to get a free Delphi 11 edition for Andreas Hausladen ... which pretty much states exactly that.

Several Embarcadero employees (one of them Matthias Eissing from Embarcadero Germany) stated multiple times that Andy could get a free copy. But apparently there are strings attached to this offer that Andy didn't like so he declined. And having read the legal paperwork involved with becoming an MVP, I have an idea why.

There shouldn't. What's your setup?

Update: I think I have now figured out how to tackle the high DPI problems in GExperts. The following dialogs should now work fine: GExperts configuration dialog Uses Clause Manager dialog ASCII chart dialog Goto expert dialog Grep Configuration dialog (but not the Search or Results dialogs) and a few others that I have forgotten. Unfortunately setting Scaled = True didn't work well enough, at least in my setup of two monitors with different size and scaling (and that's my priority, because I work with it), so I ended up with directly handling the WM_DPICHANGED message for the dialogs.

The only way of doing that, that I am aware of, is include files.

Not sure I meant this as a suggestion. It will still fail horribly if the object variable is neither nil nor a valid instance.

In theory you could create a method that checks for self <> nil and only then returns Count, zero otherwise, so the code would look simpler: for i:=0 to List.getCount-1 do Even thought the <> nil check is still there.

It just reminded me of conditional execution of statements with appended conditions: DoSomething if condition I don't remember the specifics. I rarely program in Perl nowadays.