Jump to content

luebbe

Members
  • Content Count

    113
  • Joined

  • Last visited

Community Reputation

26 Excellent

Technical Information

  • Delphi-Version
    Delphi 10.4 Sydney

Recent Profile Visitors

2662 profile views
  1. luebbe

    New Grep Expert in GExperts - need a name

    Definitely need a community vote on this. πŸ™‚
  2. luebbe

    VCL Styles and WM_SETCURSOR problem with scrollbars

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

    VCL Styles and WM_SETCURSOR problem with scrollbars

    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 ???
  4. luebbe

    VCL Styles and WM_SETCURSOR problem with scrollbars

    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. πŸ™‚
  5. luebbe

    VCL Styles and WM_SETCURSOR problem with scrollbars

    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?
  6. 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
  7. luebbe

    The Delphi 11.2 release thread

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

    The Delphi 11.2 release thread

    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?
  9. 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.
  10. 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.
  11. 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;
  12. Hi Folks, in one ouf our projects I'm using @Daniele Teti 's loggerpro library (https://github.com/danieleteti/loggerpro) instead of a homebrew logging solution. A few weeks after switching to loggerpro, a first Eurekalog bug report came in with the message: "EMonitorLockException in ThreadSafeQueueU.pas: {ThreadSafeQueueU}TThreadSafeQueue<LoggerPro.TLogItem>.Enqueue, Zeile 157 (0)". This exception is clearly raised inside loggerpro. I have already asked at GitHub (https://github.com/danieleteti/loggerpro/issues/53), but have received no reply yet. Every month or so, another of these bug reports comes in. The problem is: - I cannot reproduce/trigger it on my development PC, even though I think I can locate exactly, where and under which circumstances it happens - I don't see any obvious error in the loggerpro code - I don't see any obvious error in my code which is why I'm asking for help here. Maybe I have missed something obvious in my code... We have the following scenario: The main thread starts a background task (IFuture), which builds up an index of files for later use. Both, main and background task log their status with LoggerPro. The index updater: procedure TUpdater.Update; var LXxxFiles, LYyyFiles: TFileList; begin if FStatus = stNotLoaded then begin Log.Debug('Renewing Index', 'INDEX'); LXxxFiles := TFileList.Create; LYyyFiles := TFileList.Create; try FStatus := stLoading; ... Prepare XXX and YYY lists ... Log.Info('Check %d Xxx Files', [LYyyFiles.Count], 'INDEX'); Log.Info('Check %d Yyy Files', [LXxxFiles.Count], 'INDEX'); // Check existing files and index their content if FStatus <> stCanceled then if Process(LXxxFiles) and Process(LYyyFiles) then FStatus := stLoaded; if FAutoSave then FIndex.Save; FIndex.LogStats; Log.Debug('Status - ' + TRttiEnumerationType.GetName<TLoadStatus>(FStatus), 'INDEX'); finally LXxxFiles.Free; LYyyFiles.Free; end; end; end; If the main task needs the index, it calls the following routine: function TUpdater.WaitForCompletion: boolean; begin Log.Enter('Updater.WaitForCompletion', 'INDEX'); // Waits until the IFuture task is finished and returns its status // The calling thread is blocked while waiting Result := (FTask.Value = stLoaded); Log.Exit('Updater.WaitForCompletion', 'INDEX'); end; Log.Enter and Log.Exit are just two wrapper functions around Log.Debug that I have added to LoggerPro. The Exception occurs on the `Log.Exit` call Here are the relevant lines of the Eurekalog report: EMonitorLockException Object lock not owned. |005B7380|Application.exe|ThreadSafeQueueU.pas |{ThreadSafeQueueU}TThreadSafeQueue<LoggerPro |TLogItem>.Enqueue |157[0] | |005B61B5|Application.exe|LoggerPro.pas |TLogWriter |Log |557[5] | |0110346B|Application.exe|System.Generics.Defaults.pas | | |39[0] | |010FF5A2|Application.exe|Update.Index.pas |TUpdater |WaitForCompletion |845[4] | |010FF560|Application.exe|Update.Index.pas |TUpdater |WaitForCompletion |841[0] | Normally the update task takes some time, so the typical log output is: 2022-04-21 15:22:13:937 [TID 16780][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 15:22:13:937 [TID 16780][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 15:22:13:937 [TID 16780][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 15:22:13:987 [TID 16780][INFO ] [INDEX ] Contains 240 Files 2022-04-21 15:22:13:987 [TID 16780][INFO ] [INDEX ] Contains 4931 Entries 2022-04-21 15:22:13:987 [TID 3280][DEBUG ] [INDEX ] Renewing Index 2022-04-21 15:22:13:987 [TID 16780][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Remove 0 Files 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Check 238 xxx Files 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Check 2 yyy Files 2022-04-21 15:22:14:242 [TID 3280][INFO ] [INDEX ] Contains 240 Files 2022-04-21 15:22:14:242 [TID 3280][INFO ] [INDEX ] Contains 4931 Entries 2022-04-21 15:22:14:242 [TID 3280][DEBUG ] [INDEX ] Updater.Status - stLoaded 2022-04-21 15:22:14:242 [TID 16780][DEBUG ] [INDEX ] <-- Updater.WaitForCompletion ... Normal work continues here In some cases (no search paths defined or search paths empty), there's "nothing" to do, which results in the following log output: 2022-04-21 14:18:14:972 [TID 22208][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 14:18:14:972 [TID 22208][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 14:18:14:972 [TID 22208][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 14:18:14:973 [TID 22208][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:18:14:973 [TID 22208][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:18:14:974 [TID 14984][DEBUG ] [INDEX ] Renewing Index 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Remove 0 Files 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Check 0 xxx Files 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Check 0 yyy Files 2022-04-21 14:18:14:977 [TID 14984][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:18:14:977 [TID 14984][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:18:14:977 [TID 14984][DEBUG ] [INDEX ] Updater.Status - stLoaded 2022-04-21 14:18:14:979 [TID 22208][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 14:18:14:979 [TID 22208][DEBUG ] [INDEX ] <-- Updater.WaitForCompletion ... Normal work continues here Note that in this case the updater was finished (stLoaded) before WaitForCompletion was called. The Log.Enter "--> Updater.WaitforCompletion" line may occur anywhere between the lines of the background thread (TID 14984 in this case). This is the LoggerPro output matching the bug report. The `EMonitorLockException` occured on the `Log.Exit` call in `TUpdater.WaitForCompletion` and this line is missing from the log: 2022-04-21 14:42:03:003 [TID 20620][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 14:42:03:003 [TID 20620][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 14:42:03:003 [TID 20620][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 14:42:03:004 [TID 20620][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:42:03:004 [TID 20620][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:42:03:004 [TID 3312][DEBUG ] [INDEX ] Renewing Index 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Remove 0 Files 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Check 0 xxx Files 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Check 0 yyy Files 2022-04-21 14:42:03:008 [TID 20620][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 14:42:03:008 [TID 3312][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:42:03:008 [TID 3312][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:42:03:008 [TID 3312][DEBUG ] [INDEX ] Updater.Status - stLoaded ... Normal work continues here Note that the updater was still working (on nothing ;-)) when WaitForCompletion was called. It looks like Log.Exit('WaitForCompletion') and Log.Debug('Updater.Status - stLoaded') happen in the same millisecond, so I assume that thread 3312 still held the lock, when exception thread 20620 called `Log.Exit`. But I see this all the time (finish/exit happens in the sme millisecond) when I run the code on my PC and never get an EMonitorLock exception. Is there something we are doing wrong or have we come across a race condition in LoggerPro or the Delphi locking implementation?
  13. Apart from the obvious "length", "height" and "weight", I tend to mistype phonetically similar consonants. E.g. "t/d", "b/v" like "wader" instead of "water".
  14. luebbe

    Delphi profiler

    @FPiette do you know https://github.com/neslib/Neslib.Xml? I switched some of my xml parsing from Delphi's native parser to Neslib.Xml and it resulted in around 35x-40x faster parsing (17-20 seconds versus <= 0.5 seconds).
  15. luebbe

    Howto prevent a grid from scrolling

    Sorry no, it doesn't help. The stringgrid still catches all mouse wheel events. And there is a stack overflow in TControl.Defaulthandler when I'm not over a grid.
Γ—