MENUITEM "&Fonts", 2124 doesn't work for me

[petermad]

I can confirm that here cm_OpenFonts now opens \\WINDOWS (C:)\Windows\Fonts\ also under Windows 10

21.08.23 Fixed: cd ::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534} didn't work, use prefix shell:::{ on Vista or newer (32)

CD ::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534} opens \\Fonts also in 32bit TC under Windows 10

I consider the bug fixed

But I have noticed another thing. Under Windows 10, when I use cm_OpenFonts almost all files and folders in \\WINDOWS (C:)\Windows\Fonts\ have their timestamp changed to the current date and time, when I use the command on a new date. Has anyone else experienced that? IO don't see the same under Windows 7 and the physical files in C:\Windows\Fonts\ are untouched in Windows 10.

I will wait a couple of days and see if the same happens when using CD ::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534}.

[ghisler(Author)]

They don't get the timestamp changed when you look in c:\Windows\Fonts after using cm_OpenFonts. They just get shown with the current date and time in cm_OpenFonts. When I open Explorer and then
1. Paste the path
shell:::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534}
2. Right click on the background and choose Show - Details
3. Right click on the headers and enable the modification date header
it reports the same nonsensical dates.

[petermad]

it reports the same nonsensical dates.

Not quite - Here Explorer shows modified dates that are mostly from August 21st, Where TC shows modified dates from August 25th.

The modified dates in the physical folder c:\windows\fonts are mostly from 2019 when shown in TC.

If I navigate to c:\windows\fonts in Explorer, the same modified dates are show as if I use shell:::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534}

I wonder if it were better if cm_OpenFonts used CD ::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534} instead of cd shell:fonts - so that the directory bar would show \\Fonts\ (in the System loacale - e.g \\Skrifttyper\ or \\Schriftarten\) instead of showing: \\WINDOWS (C:)\Windows\Fonts\ After all \\Fonts\ is where you are taken if you navigate from the virtual Control Panel (cm_OpenControls) - But on the othre hand CD ::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534} doesn't work under Windows XP.

In TC 10.52 and older, cm_OpenFonts opens/shows \\Fonts\ (not localized), but in TC 11.x it shows \\WINDOWS (C:)\Windows\Fonts\ - which function did TC 10.52 use?

[ghisler(Author)]

Not quite - Here Explorer shows modified dates that are mostly from August 21st, Where TC shows modified dates fro August 25th.

That's odd, here Total Commander and Explorer report the same date+time for the fonts when I go to
shell:::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534}

[petermad]

2ghisler(Author)

Well not here: https://tcmd.madsenworld.dk/fontsdates.png

Try again after 24 hours.

[AntonyD]

2petermad
FOLDERs - have a mismatched "current" date - not a real FONTs objects in that list!
You in fact as a first elements inside this listing see the complex representations of those fonts
which has they own identical 'font family' characteristic.
For example open 'Consolas' DIR and you will see 4 objects - 4 a now real fonts:

• Consolas italic

• Consolas regular

• Consolas bold

• Consolas bold italic

and this is 4 real FILES in fact.

1. consolai.ttf
2. consola.ttf
3. consolab.ttf
4. consolaz.ttf

And it is already logical and correct to compare dates for these objects at Total and Explorer.
But alas - even here we will still get the problems of mismatch between the real dates of the files on the disk and what Total will show to us.
And as for FOLDERs - it is quite logical that there should be NO dates at all - because this is a very ephemeral pseudo-group representation that does not have any mapping on the real file system on the disk.

[petermad]

2AntonyD
I am aware that it is a virtual folder, but it seems to be a Windows 10 (11) thing touching the dates - Windows XP, 7 and 8.1 does not behave like that.

[petermad]

Tried again with shell:::{21EC2020-3AEA-1069-A2DD-08002B30309D}\::{BD84B380-8CA2-1069-AB1D-08000948F534} in TC and Explorer.

TC showed the current date and time 26-08-2023 12:45 , but Explorer still shows the same timestamp as here: https://tcmd.madsenworld.dk/fontsdates.png - so I guess TC get new timestamps when the date changes (it hasn't even bin 24 hours since last test).

[AntonyD]

2petermad
If you know for sure - that this is a virtual directory for each of the fonts from the beginning of the fonts listing - then why doesn't it surprise you at all that this directory, in principle, has a date? Just because in other operating systems you saw a seemingly correct timestamp for them? BUT AND THERE - it's not true that the virtual directory generally has such a mark. For example, if you enter the SFTP plugin, you will only see the names of the saved sessions and a mark that these are <link>s. And no dates! ALTHOUGH! potentially, the dates of the last access to these sessions could be indicated there. But there are no dates - and that's totally right!
So why should we think that displaying the time for virtual directories reflecting a font family SHOULD be done at all?

[petermad]

2AntonyD
Some Virtual folders like \\Libraries, \\Documents and \\Shared files have folders with dates, Others like \\Control panel, \\Network and \\This PC does not have dates - so there is no distinct pattern.

What puzzles me is not that \\Fonts has dates for the "Folders" or not, it is the observation that the dates for files and folders in \\Fonts are updated to current date each day when TC accesses the \\Fonts folder, but Explorer does not do that, and it doesn't happen in Windows versions below 10.

Maybe it is just an unavoidable thing in Windows 10/11, but if it could be avoided it would be nice, especially because \\Fonts is one of the few virtual folders that gives you some benefit over the corresponding physical folder.

[AntonyD]

2petermad

so there is no distinct pattern.

So why not introduce a strict regularity? ALL virtual directory objects must NOT have a timestamp!

if it could be avoided it would be nice

And this can be done if you REMOVE the timestamps for these virtual objects!
They simply do not need them for any reason!

the observation

As to this - probably Mr.Ghisler can add a more "news" about it - but IMHO
if something is used in the code that is tied directly to the Lazarus codebase, it is likely that there is simply some kind of error there.
Still, such a third-party compiler and unequal community support compared to at least C ++ Builder Embarcadero,
or even keep quiet, psst!))) - Visual Studio + SDK ....

2Ghisler - just curious - what function do you use to get the contents of those special folders?
I hope SHGetKnownFolderIDList ?

[ghisler(Author)]

Try again after 24 hours.

Seems like Windows is
- using the current date and time when it can't determine one, e.g. when there are multiple fonts in a group, and they have different dates,
and
- it's caching the virtual folder separately per process, that's why you are getting different dates in TC and Explorer.

I don't think that there is anything I can do about that when Windows reports these dates to me...

[petermad]

I don't think that there is anything I can do about that when Windows reports these dates to me...

OK.

Then I only have one question, why does TC 11.x show the folder as: \\WINDOWS (C:)\Windows\Fonts\ while TC 10.52 show the folder as \\Fonts (which I would prefer) ?

[ghisler(Author)]

TC11 now shows the whole path for virtual folders which are using multi-level deep ID-Lists. This is mainly done to access Android devices or media players which support a directory structure. It has the advantage that you now see where you are, and can go up directly to a higher level folder.

TC just gets the names of all parents and shows them like a path. I couldn't find a way to determine whether a virtual folder is an Android device or some internal folder...

[petermad]

OK, then I think the fix can be confirmed.

Moderator message from: petermad » 2023-08-27, 10:21 UTC

Moved ftom "TC11.x bug reports (English)" to "TC Fixed bugs"