dummzeuch

My guess would be: CnWizards

It's not as bad as it sounds. I have one version of each component package installed in the IDE and that's used at design time regardless of which version of the sources are compiled into the project. When I make any changes to the controls I keep an eye on the dfm files for properties that might not be compatible with the active version of the controls and revert them when committing to source control, but given the mature state of the components that's very rarely the case. Source code and dcus of 3rd party libraries is not in the IDE's search paths but only in those of the project. The source code itself is always an svn:external to the project sources, so it's in a subdirectory of the project and all entries in the search path are relative to the project. We always compile from sources, including 3rd party sources, and don't use packages. I have several installations of the IDEs on different computers, but that's for debugging purposes only (due to specialized hardware these programs need to access) not to keep different versions of the controls. We develop with Delphi 2007, XE2 and now 10.2. XE2 projects are slowly being upgraded to 10.2. Some 2007 projects need to stay with that version until we finally phase out the last Windows XP machines (planned for this winter), then these too will be moved to 10.2. I blogged about this several years ago (when life was still a bit simpler, but the general principles still apply http://dummzeuch.de/delphi/subversion/english.html

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