dummzeuch

That's why it also scans the browsing path. Sorry, I should have mentioned that. Otherwise it wouldn't have found TStringList in Classes: So, the problem is, that it is too slow? Or what else do do you mean by cumbersome? I am trying to learn what to improve. For me it currently is fine (less than a second delay on the two computers I mostly work on, I wonder what makes it so slow on your computer), so I rely on others for suggestions.

you press the shortcut that calls the expert if the Identifier tab is not yet active (the dialog remembers which tab was active), press the shortcut (Alt+I) for that if there is a perfect match, the required unit will automatically be selected, so you press Alt+C or Alt+L to insert the unit into either the interface or implementation section if the expert is configured for - oops? - I thought there was an option to automatically close the dialog after adding a unit? OK, apparently somehow this option got lost, I need to look into that - you press enter to close the dialog So, if there is a perfect match, 3 key presses / combinations are required. If there isn't, you can either use the filter or the keyboard keys to select the correct identifier / unit to insert. The expert uses the current search path to determine which units are available. One drawback of this is that it might take a few seconds to determine the units and parse / cache the identifiers when invoked the first time for a project and display them. There definitely is still room for improvement here. But on a computer with an SSD it's very fast, on a HDD it's not too bad either.

Since I seem to remember that you mentioned that you use GExperts: The description of your plugin sounds a lot like the Identifiers tab of the Uses Clause Manager. What functionality are you missing there that you went to the trouble to write your own?

What is the latest Delphi version that can be installed and used on Windows XP? I know that XE2 and XE3 work, and I seem to remember that XE4 also does.

What about putting the labels/radio buttons above the input fields? That would work even if scaling fails.

So far above that it can be read at design time. The scaling of the form should take care of different DPI. As for the layout: I never bothered to use anything but the default for labels.

Put the label above the edit field.

Today I had a very strange compiler error in Delphi 10.2, that occurred on one computer but did not occur on another computer: myUnit.pas(28): error F2613: Unit 'TeEngine' not found. The project was checked out from svn on both computers, so the source code was identical. So the unit “VCLTee.TeEngine” from TeeChart was in a subdirectory of the project sources and the project’s “Search Path” on both computers. But on one computer the compilation worked fine, on the other I got the error above. The first thing I checked was that the TeeChart sources were not listed in the “Library Path”. I restrict my “Library Path” to the RTL and VCL units that come with Delphi and remove anything 3rd party libraries tend to add. Third party sources go into svn, are project specific and checked out via svn:external. Further investigation showed that the prefix “VCLTee” was not listed in the Unit Scope Names setting of the project, that’s why the compiler as only looking for “teEngine” and did not find “VCLTee.TeEngine”. But again: How could the same project compile on the other computer? It should have failed on both! read on in the blog post.

I blogged about installing it on Windows 8.1, which also works on Windows 10 if I remember correctly. Getting the dotNET version it needs proved a bit more challenging on one computer (on others installing dotNET 3.5 simply worked). I also blogged about that. (I mostly blog about those things so I can look it up if I need it again.) Edit: I'm not sure whether I ever installed Delphi 2006 on Windows 10. On my current computer, I installed it to Windows 8 and upgraded that to Windows 8.1 and later to 10. It's possible that installing directly to Windows 10 is more involved.

I just released dzBdsLauncher 1.0.6. The only change is support for detecting .dproj files created by Delphi 10.4.2 (these have a ProjectVersion of 19.2). If you don't know this tool yet, here is the description:

BDS2006 does actually work on Windows 10. Every Delphi version since Delphi 6 does. Some need tweaks though. But using a VM is a good idea anyway, if it can be done for the type of development you are doing (I can't unfortunately since I need to access custom hardware and the remote debugger never worked for me.) Why shouldn't it? I have been running both in (XenServer) VMs only.

This particular issue should now be fixed. Unfortunately that doesn't mean that the effect is gone. I have still seen the grep window being empty when docked. switching to a different tab brought it back. Still no idea what the actual problem is.

I know that XE3 works fine on Windows XP. I started this topic to find out which was the last version that did. (Which does not mean that it's officially supported. So the documentation doesn't mean much unless it states a technical reason.) I'm still not sure that 10.2 doesn't work at all, it might still be an installation issue. Since the web page URL contains the word "tamper" it could be that it "detected" something in the installation it didn't like. The web page, that does not (no longer?) exist, might have contained information on the specific issue (but probably didn't). On the other hand ... ... that would mean a definite no. But then, there is:

I just tried to install Delphi 10.2 (Tokyo) on Windows XP. The ESD-Installer refused to run. The one from the ISO started and the installation finished successfully. But on the first start, a browser window opens to http://installers.embarcadero.com/tamper?Version=25.0.29899.2631&Code=00409116 which times out. That's it. Not quite what I was expecting.

Wasn't there an option now to have the embedded form designer on one screen and put an undocked secondary editor window on a second screen? I seem to remember reading a blog post about this.

The constant also exists in Delphi 6, value is 14. Older versions don't have it.

Hm, I thought I had fixed that particular issue by restricting the allowed values for that setting. Need to look at this code again.

Unlikely.

There are the CompilerVersion and RtlVersion constants, but they are not the values you would want to display.

I'm afraid even that is probably just coincidence. I also get this error once in a while. Unfortunately I was never able to find the actual cause. The assertion message is just a side effect. The issue is that the resources that assertion checks for, are not freed. The easiest "fix" would be to remove the assertion. Fortunately it only happens when exiting the IDE, so it's mostly a nuisance.

After looking into general spin locks I now had a closer look at TCriticalSection and the internally used TRtlCriticalSection record with associated API functions. One thing I didn't know about is the SetCriticalSectionSpinCount API function which allows to adjust the SpinCount of a CriticalSection, in theory that is: My tests on my computer with Windows 10 have shown that using SetCriticalSectionSpinCount after initializing a TRtlCriticalSection with InitializeCriticalSection has no effect at all. It only works if either InitializeCriticalSectionEx (Windows 7 and later) or InitializeCriticalSectionAndSpinCount (also available in Windows XP) is used for initializing it. The SetCriticalSectionSpinCount will only then actually change the SpinCount. I couldn't find anything about this in the documentation, but maybe I wasn't looking hard enough. Also, apparently Microsoft has changed what InitializeCriticalSectionEx does. If has a Flag parameter which according to the documentation can be set to CRITICAL_SECTION_NO_DEBUG_INFO to prevent debug information to be generated. But my tests show that this has no effect at all on Windows 10. To get debug information, one has to specify the undocumented flag RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO. Again, maybe that's documented somewhere but I didn't find it. Something else I learned is, that a Delphi RTL's TCriticalSection also has a TryEnter method which calls the TryEnterCriticalSection API function. Somehow I missed that for all those years. The test results are also interesting on how different SpinCounts affect the general throughput for different numbers of threads. The default (which seems to be 2000 but I am not sure about this, as it is set dynamically by Windows and may depend on the hardware and the system load) is generally OK but using 100 gives a much better throughput in all my tests with different numbers of threads. Simple+Sleep is a "spinlock" that only checks for access and then calls Sleep(1) TdzCritSectTest uses a TRtlCriticalSection initialized with InitializeCriticalSection TdzCritSectTestInit100 uses TRtlCriticalSection initialized with InitializeCriticalSectionAndSpinCount to SpinCount of 100 But these tests are very synthetic: I have n + m threads running in an endless loop until aborted: The n writers execute this code: procedure TLockTest.doWrite; var i: Integer; Value: Integer; begin AcquireLock; Value := Random(100); for i := 0 to Length(FDataToSafguard) - 1 do FDataToSafguard[i] := Value; ReleaseLock; end; FDataToSaveguard is an array of 10 integers. The m Checkers execute this code: procedure TLockTest.doCheck; var i: Integer; Value: Integer; begin AcquireLock; Value := FDataToSafguard[0]; for i := 1 to Length(FDataToSafguard) - 1 do if FDataToSafguard[i] <> Value then InterlockedIncrement(FErrors); ReleaseLock; end; So they not only read the data but also check that it is correct (that's why I call these "checkers" rather than "readers"). The reason for this code is that I wanted to make sure that the array is actually being protected because this test was also meant for my homegrown spinlock code. I'm not sure what to make of this regarding real world code because it's very rarely that it doesn't matter which thread gets executed how often. E.g. if there is one or more writers filling a queue of some kind and one or more readers emptying it, it can happen that readers become idle if writers don't get access to the queue. In that scenario a high "throughput" as measured by my test program won't be a good thing. I guess I'll have to come up with a better test. If you want to look at the code, it's in my dzlib repository on OSDN: https://svn.osdn.net/svnroot/dzlib-tools/dzlib/trunk TdzRtlCriticalSection is in src\u_dzCriticalSection, the test is in tests\SpinLockTest. (Yes, I should probably have made this a blog post....)

None at all, this was purely out of curiosity. Thanks for the links.

That's just coincidence. The changes only applied to forms using TStringgrid with custom drawing and an error that occurred when registering GExperts via rundll32. All those only apply to the Delphi 10.4 version, that's why I didn't try to compile other versions and overlooked the missing unit.

Ooops, yes, I forgot to add the new unit to the other projects.

Fixed in revision #3450. Thanks.