dummzeuch

It's a common misconception that all software development should and can be done in virtual machines.

fixed too (same fix as for the Expert Manager) The reason was that I tried to avoid flicker when adjusting for DPI changes which had the side effect of prematurely showing that form during construction.

fixed

fixed

I only tried Delphi 11 before committing the changes. Thanks for letting me know. That is one of the dialogs I didn't test (obviously). But this is a rather odd error. I'll check that.

I think I now got most of the modal dialogs show correctly in highDPI. There will probably be some glitches as I haven't had time to test them all yet.

No, I don't, I haven't memorized all features of GExperts. And I wasn't asking you.

There generally are two possibilities (I don't know which applies and I don't have the time to look it up): 1. It's a missing feature: In this case, file a feature request. 2. It's a bug: Then you have two options: 2.1 Find the bug and fix it 2.2 File a bug report and wait for somebody else to fix it.

I must have screwed something lately, because nearly every time I close the IDE (any version of it) I get an access violation. The only reason I can think of is that I made a change to GExperts that causes it. Does anybody else, who recently compiled GExperts from sources, experience the same problem?

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.