Mike Torrettinni

Other languages offer such feature?

Could this fall into the same category, or is this valid case?: in Delphi 10.2.3 Vcl.ActnMenus: procedure TCustomActionMenuBar.ProcessMessages; var Msg: TMsg; begin while ProcessMessage(Msg) do; end;

Will post when I make progress.

Thanks, if this was a major feature I need, I might take on the project.

Why would you suggest that? I would prefer Delphi solution, do you know of Lucene in Delphi?

True, but I'm not trying to put pressure on Thomas so I'm only asking what is possible right now and if I'm missing something really obvious like I did with option Parse map file.

I can only enable this option if I search Directories and not files. Do you know if this option (Exclude dirs) can be enabled and applied to search All files in project/All files in project?

Aha, it works only on project files if I temporarily rename rtl source folder, to source_.

Yes, I do have Map file as detailed in Linking option, and it works when I choose Parse map file, thanks! But now I get also RTL and other (Indy...) .pas files in search results, when searching for something that I guess appears in these source files, too. What setting could it be that doesn't include Delphi's source files?

Do you know how it can search through units that are not defined (used) in .dpr, but are used in the project? If I select All files in project it doesn't search in units not defined in .dpr.

I think I could instruct to use double-quotes for or/and and other operators, like it's used for phrases: "or customer" or "and customer" or "or" or "and" ....

Yes, I think you are right. Probably I can make it work with a lot of modification to fit within case like this: I think this would require quite a modification of expression from: 'john or peter' to 'user = john or user = peter'. I assume to actually replace Pos(), would need to use LIKE (or CHARINDEX) SE.ParseString('user LIKE ''%john%'' or user LIKE ''%peter%''');

User input search string, yes like google. I mean simple edit box. No nested levels at this point. Thanks for suggestions!

Yes, it's very powerful component, shame it can't parse expressions that are not pure SQL. I could probably customize my expression to add 'SELECT' and other sql keywords to parse, but that is not what I'm after.

It's triggered on user input, so no need for super fast. I do have 'instant search' (search as you type), but this is not applicable for complex cases or if you type really fast, I guess under 1s should be just fine. Oh, I do have highlighting of text for visual representation, but that only works on a found results, so doesn't need to be super fast, either. Thanks, you gave me a lot to think about!

Thank you @Kas Ob., yes SQL is not on the table.. unless all other options are too complex to implement, but I doubt it. I was thinking similar thing as you to parse expression and build some logical expression out of it and then run on text. But my idea was (just an idea so far) to run a full logical expression on each string, while your suggestion is to create lists based on parts of expression and then combine/cross-sect lists as operators say, right? So, my idea was to parse expression to end up with something like: this is as stage 3) in your example function EvalPhraseInText(const aText: string): boolean; begin Result := ((Pos('text_phrase', aText)>0) OR (Pos('testing', aText) > 0 ))// replace AND Pos('text', aString) > 0 OR (Pos('anything else', aString)> 0; end; of course, I have no idea how to get to this point, at the moment, as this would be point 2) build logic flow. I assume you thought of this approach when you were working on your solution and decided that is not as good as your solution.

EDIT: The 3 options I'm showing here are what I use now in my code, and other even less clean and less maintainable examples of code to get enum names. But I narrowed down to these 3 and now I'm deciding which one will be the one I choose to refactor into. I'm refactoring some enum usage and was testing 3 ways to convert enum to string: TEnum = (enOne, enTwo, enThree, enFour, enFive, enSix); 1. (ToString) Using Magic strings: case Self of enOne : Result := 'One'; 2. (ToString2) Using string consts: const cOne: strig = 'One'; ... case Self of enOne : Result := cOne; 3. (ToString3) Using array of enum of strings: const cEnumStr: array[TEnum] of string = ('One', 'Two', 'Three', 'Four', 'Five', 'Six'); ... Result := cEnumStr[Self]; I prefer the 3rd way, but wanted to test to see results. Looking at the asm, looks like 3rd option could be fastest, but the results show only negligible ToString ToString2 ToString3 The results are pretty much same, negligible difference: 6 runs: And code: program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Diagnostics; type TEnum = (enOne, enTwo, enThree, enFour, enFive, enSix); TEnumHelper = record helper for TEnum function ToString : string; // use Magic strings function ToString2 : string; // use const strings function ToString3 : string; // use array[TEnum] cost of strings end; const cEnumStr: array[TEnum] of string = ('One', 'Two', 'Three', 'Four', 'Five', 'Six'); cOne : string = 'One'; cTwo : string = 'Two'; cThree : string = 'Three'; cFour : string = 'Four'; cFive : string = 'Five'; cSix : string = 'Six'; const cLoop: integer = 1000000; cNoOfTests: integer = 6; cNoOfEnums: integer = 6; function TEnumHelper.ToString: string; begin case Self of enOne : Result := 'One'; enTwo : Result := 'Two'; enThree : Result := 'Three'; enFour : Result := 'Four'; enFive : Result := 'Five'; enSix : Result := 'Six'; end; end; function TEnumHelper.ToString2: string; begin case Self of enOne : Result := cOne; enTwo : Result := cTwo; enThree : Result := cThree; enFour : Result := cFour; enFive : Result := cFive; enSix : Result := cSix; end; end; function TEnumHelper.ToString3: string; begin Result := cEnumStr[Self]; end; procedure Run1; var i, j: integer; vStr: string; begin for i := 1 to cLoop do for j := 0 to Pred(cNoOfEnums) do begin vStr := ''; vStr := TEnum(j).ToString; end; end; procedure Run2; var i, j: integer; vStr: string; begin for i := 1 to cLoop do for j := 0 to Pred(cNoOfEnums) do begin vStr := ''; vStr := TEnum(j).ToString2; end; end; procedure Run3; var i, j: integer; vStr: string; begin for i := 1 to cLoop do for j := 0 to Pred(cNoOfEnums) do begin vStr := ''; vStr := TEnum(j).ToString3; end; end; procedure RunTests; var vSW: TStopWatch; i: Integer; begin for i := 1 to cNoOfTests do begin vSW := TStopWatch.StartNew; Run1; vSW.Stop; Writeln('ToString: ' + vSW.ElapsedMilliseconds.ToString); vSW := TStopWatch.StartNew; Run2; vSW.Stop; Writeln('ToString2: ' + vSW.ElapsedMilliseconds.ToString); vSW := TStopWatch.StartNew; Run3; vSW.Stop; Writeln('ToString3: ' + vSW.ElapsedMilliseconds.ToString); end; end; begin RunTests; Readln; end. Anybody knows of any faster options?

Thanks. Nice, very good to see this progress!

If anybody wants to test GetEnumName vs other tests, this is Run4 I added to the original tests: uses System.TypInfo; procedure Run4; var i, j: integer; vStr: string; begin for i := 1 to cLoop do for j := 0 to Pred(cNoOfEnums) do begin vStr := ''; vStr := GetEnumName(TypeInfo(TEnum), j); end; end; ... vSW := TStopWatch.StartNew; Run4; vSW.Stop; Writeln('GetEnumName: ' + vSW.ElapsedMilliseconds.ToString); Perhaps anybody with 10.3 or 10.4 will see improvement in RTTI, versus my 10.2.3 version.

I just added Edit to my first post. I hope it gives more context on the purpose of this topic.

Thanks, very well written! I think not using magic strings is first step towards your first rule, no?

I have a few benchmarks ready for Delphi 11. I know 10.2 has certain limitations with inlined functions,, even compared to 10.3, 10.4. I hope 11 will not regress.

'Too deeply' is quite vague, can you be more precise in your suggestion how to refactor my code?

I really wish I didn't need to refactor the code, but in some cases the maintainance was taking too much time so this change was neccessary. Years ago I didn't know that there are better ways than to hardcode string values. So i really can't see this change being a waste of time.

Thanks, this make sense. I like option 3 because, like you said, is easier to maintain. Good to see others agree.