Recent

Author Topic: Filter improvments for "Search Results" window / and others  (Read 1677 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9867
  • Debugger - SynEdit - and more
    • wiki
Re: Filter improvments for "Search Results" window / and others
« Reply #15 on: June 07, 2023, 05:48:38 pm »
Quote
I still think alternatively / optional escaping with \ is a good idea too. Many people are used to that too (like in regex). And if we have global options, then it is easy to toggle.

I don't see any need to reserve one more character. To escape one character (or any number), you can use the same quotes directly in the text:

'text,text' <=> text','text

Why <=> ? should those two then not be equal?

In the 2nd example the first ' is directly after the "t" => so there is no space => no new sub-term starts => the current term continues. The "," is no quoted, and therefore not a separator.
That is the same as the first string?

I wonder, if it would be more "natural", if a ' in the middle of text would be an escape for the single next char?
Code: Text  [Select][+][-]
  1. abc 'd e f'   // ' is after space, so it starts a string, and needs a closing quote (or acts till end of text)
  2. abc d' e' f  // ' are after non-space and escape the very next char only => this can only happen if there was no opening '
  3.  



Would work, I can live with it. Curious what others think....

n7800

  • Jr. Member
  • **
  • Posts: 91
Re: Filter improvments for "Search Results" window / and others
« Reply #16 on: June 07, 2023, 06:06:46 pm »
Quote
Why <=> ? should those two then not be equal?
Yes, they are equal. I just wanted to use the math equivalence sign ))

Quote
I wonder, if it would be more "natural", if a ' in the middle of text would be an escape for the single next char?
The quotation mark is a pair character. And it's easier to see it that way. If the first quote mark is encountered, then the entire text will be "solid" until the next one. And it doesn't matter where she is.
This is easier for both humans and parsing.
I think we need to reduce the number of "special cases".

n7800

  • Jr. Member
  • **
  • Posts: 91
Re: Filter improvments for "Search Results" window / and others
« Reply #17 on: June 07, 2023, 06:14:27 pm »

Quote
Yes, I wanted to suggest something similar, at least for TTreeFilterEdit and TListFilterEdit.
Shouldn't it be in the base class ?


Yes, of course, if possible. You probably know better which of the base classes.

n7800

  • Jr. Member
  • **
  • Posts: 91
Re: Filter improvments for "Search Results" window / and others
« Reply #18 on: June 07, 2023, 06:24:46 pm »
Quote
It may have a name like: "AllowOnlyASCII" or "OnlyQWERTY".
Or should it be a an enum?
- Only Latin
- Only digits (that may be of interest(
- Only digits, and dot or coma (locale dependent)
- Only Latin chars
- Only Upper (or only lower) // that may be better with a "set of enum"

Or a String, that contains all allowed chars. If that string is limited to #32..#127 it can be turned into a set for lookup.

I think you've confused this feature a bit with "input mask". The input mask does not allow you to enter other characters (for example, letters instead of numbers), but this function automatically "converts" the characters to the correct ones. Switching the keyboard layout is not required. And I think this function is needed only for one layout - "QWERTY" (that is, ASCII).
So it's just one boolean property.

n7800

  • Jr. Member
  • **
  • Posts: 91
Re: Filter improvments for "Search Results" window / and others
« Reply #19 on: June 07, 2023, 07:00:53 pm »
Quote
Though I would leave it at one global option "Filters use extended syntax" (checkbox on/off).

Well, then I like it. Then you won't need to add an option to each window, everything will be in the filter itself.
You can even do it as a separate button, as there is now a button to clear the filter (if a certain property is set in the filter itself)
By the way, when you hover over this button, a hint can be displayed, in which there will be a little help on the search. This will help people in the beginning.

Similarly, there may be a button to enable "auto-transliteration".
  • users will immediately notice the new feature (and this is important, because by default it will be disabled)
  • their state will always be visible - no need to open the context menu
  • it will be convenient to switch them (but only with the mouse, so they should also be specified in the context menu to enable them from the keyboard)

 

TinyPortal © 2005-2018