Might be a bug !

[Kas Ob. 119]

Hi @Uwe Raabe ,

I saw this bad behavior from MMX code explorer for years now, yet it didn't annoy me that much as i do restart my IDE frequently, but today was with a client sharing his desktop with me, while i am helping him to track a bug in his project on his PC and on his client PC who was also sharing his desktop, so the process went for some times and among few tools being used one reported something that caught my eye, so at the end of this semi-teaching session i tried to confirm that behavior (the one i am familiar with) on his Delphi 10.3.

 

Now to the details, my IDE is XE8 and i have MMCE v13.1.0 build 2220 while his IDE was 10.3 and i forgot to write his MMCE version and build but it was v15 for sure, he said it was the latest, but after visiting https://www.mmx-delphi.de/ i can't know what is what and where is the latest version or if there is beta and stable....

 

Anyway, to the problem at hand : any already opened then closed file using the IDE MMX will keep tracking and monitoring its datetime, and here i mean it will do it only if closed after opening, this accumulate with what looks like no limit, i opened 50 files and opened and closed many different projects and the IDE with nothing opened keep checking these file datetime (namely FileAge) exactly every 1 minute, and on top of that the same query for FileAge happen every time the IDE was activated (like restored or even had focus after losing it) 

 

Again the following on my XE8 and the deprecated v13, yet i saw the same behavior on v15 and newer version but i couldn't ask my client to waste time for something might not concern him.

This capture is the simplest using Process Monitor and one opened and closed file after activating the IDE 

and this does show the 1 minute timer triggered FileAge

 

These are with one file opened and closed, also i can't make much sense from the call stack !!! 

I mean triggered by DoActivate makes sense, yet these are closed files and should not be monitored, because they are monitored, here an example of that file being renamed then opened and closed then renamed back 

 

About the stack and make sense, this sequence

AddClipboardFormatListener -> TDataModule.WriteHeight ???!!!!!!!(WTF)  -> MMCE  then MMCE even with non existed file keep trying to query its information, though there is a hook and the timed query should not be needed to be begin with, ( not with a timer and not on IDE activation)

Something wrong here and there is no clipboard what so every on my PC now, and to be honest i not sure if the stack is correct at this point.

 

Anyway, hope i am not wasting your time and please forgive me if i am missing something obvious like some settings for such caching and keep it even after closing, as i couldn't find settings to control this behavior .

 

PS : today i had blackout twice and every time lost around half an hour of debugging session deep into the IDE and MMCE, so i gave up and decide to report it, 

between these files query, there is a loop and to walk the files but one forward and the other downward (may be while-do vs for-to) the code responsible for FileAge in knownache or chached ... etc i really can't remember, and doubt it is useful, as going after FileAge should be more than enough.

 

PS2: I am not expecting any update on v13 also don't have the right to ask for, but it might help v15 users if the mentioned here problem is in fact a problem and still exist in the latest version.

PS3: i successfully solved or removed the my problem on v13 by hooking, though not sure what did break if any, no signs of MMCE failure with few restarts and few fast tests.

 

PS4: there is difference in the call stack for these closed files may be about 30 seconds then it will revert to different stack call (deeper/longer one)

 

Hope that is not waste of time.