Hi,

So, now we have:
TMask
TMaskWindows
TMaskList

TMaskList also caters for the old TMask.MatchesWindowsMask.

However, now that we have a dedicated TMaskWindows, wouldn't it also make more sense to have a TMaskListWindows class?

The TMaskList constructors
    constructor CreateWindows(const aValue: String; aSeparator: Char;
aOptions: TMaskOptions);
    constructor CreateSysNative(const aValue: String; aSeparator:
Char; CaseSensitive: Boolean);
would not be necessary anymore.

For the TMaskListWindows we only need the constructor with the new syntax, and the class would be rather simple.

On Tue, Oct 26, 2021 at 8:24 PM Bart via lazarus <

Yes, sounds OK, but it cannot cover CreateSysNative which is now used in procedure TFileSearcher.Search.
The IFDEF can be placed there directly of course.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211026/477b7fff/attachment.html>

PM Juha Manninen wrote

Yes, sounds OK,

I'll have a go at it then

but it cannot cover CreateSysNative which is now used in procedure TFileSearcher.Search. The IFDEF can be placed there directly of course.

Probably better.

PM Bart wrote

So, now we have: TMask TMaskWindows

About naming:
We have MatchesWindowsMask(List), but TMaskWindows. That's not very logical or consistent.

Either we should rename TMaskWindows to TWindowsMask, or fase out MatchesWindowsMask(List) in favour of MatchesMask(List)Windows.

PM Bart wrote

I'll have a go at it then

To simplify matters I decided to remove the CreateWindows and CreateNative constructors for TMaskList.
The CreateWindows skipped the population of fMasksWindows, but that is a small price to pay IMO.
I can't have this as a constructor in TMaskListWindows, but I would inherit it, so I got rid of it.
So, for the moment TMaskList always internally creates and populates 2 lists.

I tried to use a factory pattern, , so that I would not have to replicate the Matches method for TMaskListWindows. I factored out populating the respective objeclists (fMasks and fWindowsMasks) and made that a virtual method so I could override that in TMaskListWindows.

That has it's drawbacks however: in TMaskListWindows I have to iterate through fMasks in order to set some privae variables/fields of the created TMaskWindows instances, and then have to call the Compile method.
(Duplicating some actions in the TMaskWindows constructor, so that possibly needs updating when TMaskWindows constructor gets changed).

The problem turned out to be the fact that:
FMaskClass.Create(S[i], CaseSensitive, aOpcodesAllowed) does not call the TMaskUtf8Windows constructor, when FMaskClass definitely _is_ TMaskWindows (it calls TMaskUTF8 constructor directly).

This probably is because the signature of te constructor has a long list of default parameters.
Unfortunately you can't override that constructor in TMaskUtf8Windows: you'll get a "Error: Can't determine which overloaded function to call".

So, I untangeld all constructors for TMaskUtf8:
    constructor Create(const aMask: String);  (1)
    constructor Create(const aMask: String; aCaseSensitive: Boolean);  (2)
    constructor Create(const aMask: String; aCaseSensitive: Boolean;
aOpcodesAllowed: TMaskOpCodes); virtual; overload; (3)

Then in TMaskUtf8Windows I override the last one (3) to call the constructor with "quirks" parameter.

It may look a bit messy, but AFAICS all possible constructor calls still work. (I had to add "overload" to constructor (3), otherwise constructors (1) and (2) were not visible in TMaskWindowsUTF8, something about constructors which I did not know).