luebbe

Still waiting (and hoping)

Only about 500 for me. After I knew what was going on, I replaced them all. A systematic search & destroy did the job for me.

In fact that's what I did. I concatenated the tabs with "+ #9 +" since they separate the string anyway. Thanks for the hint.

Hi Folks, I've come across a strange bug with string literals in Delphi. I am in the process of moving from Delphi 11.3 to 12.1 and suddenly one of our tests fails. I could narrow it down to a combination of the less equal or greater equal unicode characters in combination with a tab in the string. Here's the definition: const cExpected: array [0 .. 4] of string = ( '1 Line with <= and no tab', '2 Line with ≤ and no tab', #9'3 Line with ≤ and a', #9'4 Line with ≥ and a tab', #9'5 Line with >= and a tab'); On the left side of the screenshot is the result of the misinterpretation. You see that somehow the first characters of the last line that didn't contain a tab *and* a greater equal/less equal character overwrite the first characters of the lines that contain both. I've never seen this before. Does anyone have an idea what is going on here? Delphi 11 handled it correctly. Originally it was one const separated by sLineBreak instead of a const array of string. This combination also damages TestCase() Attributes in DUnitX. They also get misinterpreted.

Definitely need a community vote on this. 🙂

Exactly, so I will move on. At least this topic is conserved for posterity, so maybe it'll help someone else as well.

We know the following: An exe produced by someone else with 10.2 is ok An exe produced by me with 10.4.2 is not ok An exe produced by someone else with 11.3 is ok An exe produced by me with 11.3 is ok (tested it in the mean time) Open question: An exe produced by someone else with 10.4.2 is ???

So it looks like a regression in 10.4 (or 10.3) to me. Thanks a lot again! In German we got the nice word "Verschlimmbesserung" for this. A mashup of Verbesserung = improvement and Verschlimmerung = aggravation. 🙂

Thanks for testing. Interesting. I wonder if this bug only happens with 10.4? I guess that my 10.4.2 exe shows the described behaviour on your PC?

Hi Folks, I've come across a problem with VCL styled applications. Some controls (not all) continuously fire WM_SETCURSOR messages, when the mouse cursor is stationary over a scrollbar and VCL styles are active. When the standard Windows style is used, everything works as expected. There are a few WM_SETCURSOR messages and they stop coming, when the mouse stops moving. This may not sound like a big deal, but on my PC the CPU load goes up from 1% to 15%..20% (one core almost at 100%) when this happens. We have a timing critical application, where the timing goes haywire, when the mouse is over a scrollbar of a TListView or a TScrollBox. At least ListView and ScrollBox exhibit this behaviour. EasyListView and VirtualStringTree don't. I haven't found the source of the problem yet, so help is greatly appreciated. Attached you will find an example with a TListView that exhibits the behaviour. Included is an .exe, compiled with Delphi 10.4.2. So if this doesn't happen with a newer compiler, we have a big incentive to upgrade 🙂 StyledWMSetCursor.zip Cheers & thanks Lübbe

I deleted the Parnassus registry keys from "SOFTWARE\Embarcadero\BDS\21.0\Experts" and now the 10.4.2 IDE starts again. Getit still thinks the parnassus plugins are installed, but uninstalled them via getit and it seems ok now. I then let the 11.2 installer delete all 11.x registry keys and it looks like it will now proceed successfully. So it looks like I could solve the problem.

Not a good experience for me so far. I had installed 11.1 alongside 10.4.2 without any problems. I always install from ISO with local admin privileges. Getit packages are installed later, normally without admin privileges. I let the 11.2 installer uninstall the previous version keeping the registry keys. It removes getit packages, finishes installing the core and then crashes with the following error: Running the 11.2 installer again yields the same result. Worst of all, when I now start Delphi 10.4.2 it also crashes with almost the same exception: So the 11.2 installer managed to destroy two installations in one go. But the parnassus dlls seem to be in place: How can I recover from this situation? Probably there are some registry keys which I should delete and then reinstall again, but which registry keys?

Got the point, thanks 🙂 I was missing the obvious part that the call stack doesn't make sense. Been digging through the RTL to find out when a EMonitorlock Exception would be raised.

You're right, the call stack doesn't make sense. I'm using my own fork of loggerpro (https://github.com/luebbe/loggerpro.git) and made two PRs with additional functionality in the original, but I didn't modify any of the queuing code. We're using a very old version (6.x) of Eurekalog. Perhaps this is reason for the wrong stack trace, but still I wouldn't expect any exception to happen here.

FTask is an IFuture, so yes, it should wait. I just mentioned this fact but didn't show any code. Here it is: procedure TUpdater.UpdateIndex(const ASearchPathList: string; AForceUpdate: boolean); begin ... cancel running tasks etc ... FTask := TTask.Future<TLoadStatus>( function: TLoadStatus begin Update; Result := FStatus; end); end;