[SEARCH] Length of search box

[FrankSchuehlein]

Hi Vlad,
As search strings can get quite long maximum space for search string is required but input line for search string is reduce due to check box for "Cont. analysis" + drop down for "Number of threads"
=> would it be possible either removing them e.g. by shifting them to right-click menu or at least shrink them?

Thanks,

Frank

[svlad-90]

Hi Frank,

I was thinking about your request.

It is really possible to remove all the UI items from the line, where the regex line edit is located. Most probably, I will do this as part of this issue.

=> But - will that solve your issue if we would think of the regex which is >1000 characters in size? I'm not sure about that.

We work on the same project, thus I know how big might become the used regular expressions. Especially, if you form a combination from the several pre-saved regex patterns.

---

What do I propose?

Before fulfilling your request I propose you to get familiar with the following functionality of the plugin: https://github.com/svlad-90/DLT-Message-Analyzer/blob/master/md/filters_view/filters_view.md

It is already possible to create so-called variables - the important parts of the regexes, which is possible to modify in a separate "Filters view". That might be the thing you are searching for.

Moreover, that part allows not only to traverse and edit an important subset of the regex expression, but also:

• Visualize the whole complex regex as a tree view. You can turn off filtering out only variables. In such a case, all "Text" and "Group" parts will be shown as separate levels of the tree view.
• Variables do support the auto-completion, thus, if you will work with standardized tracing it would be possible for you to become even more efficient with your trace analysis.

---

=> In case if above-mentioned functionality is not enough - let me know.

---

The alternative, which I can propose, is the additional widget at the bottom of the screen, which the user can optionally turn on. It will be located somewhere at the "red square area", which is shown on the below screenshot:

That widget will consist of the clickable elements and a line edit:

The idea is to split the content of the regex inside the main line-edit in parts by the "or operator" ( by "pipe" - "|" character ). And then, to allow the user to jump between those high-level parts so that he could separately see and edit one selected part. That part will for sure be smaller than the whole regex, with a pretty high chance that its content will fit into the single-line editor.

---

Another option that I can propose is to allow the user to select in runtime between the single-line edit widget, which is used now, and plain text edit, which is a resizable multiline widget. Then the user ( if he wishes) will be able to see the regex as plain text. Refer to the console view in order to see how it will look like:

Something like above, but only with the content of the regex. Turn on your imagination ☺

---

=> Please, let me know, whether "Filters view" covers your need. If not - which of the above solutions would be preferable from your POV? Or, maybe you stick to the original idea to simply hide several UI items and think that it will be enough?

---

Looking forward to receiving your feedback.

[FrankSchuehlein]

Hi Vlad,

I think I got the idea of the filter variables replacing and shortening the search box. But I have to admit that I was unable to access this filter view :-/ and therefore didn't use it yet
In docu I did not find hint how to access this yellow-orange view => could you give me hint how to do this?

Personally I think this is a bit overwhelming in beginning: on the the one hand very powerful but on the other hand statements as "(?<VAR_TRACE_SPAM_APP>[A-Z0-9]{1,4})" are not easily typed.
If you get used to it and have a bunch of filter sets to combine then this is very powerful.
Currently I have a bunch of predefined sets of regexes which are activated based on topic of analysis and later on modified as required. It's obvious that regex statements can get longer but
up to know it fits to screen size although it gets sometimes too long. Here I wondered that screen size is reduced unnecessarily with "Cont. analysis" and "Number of threads"
=> Hiding these two elements is a good in any case. At least to me they do not make sense at this exposed position but it would be sufficient having them in some submenu

Concerning you proposal of clickable elements bellow search box to enable/disable:
My understanding is that several search strings are behind each clickable element and each element can be (de-)activated to add/remove regex part
=> This idea sounds great and allows having multiple search input lines which can separately be (de-)activated. By default only one search line could be active together
with a button to add an additional search line. Each element could be closable and then element would disappear. Each search line could be filled with presets from left menu as it
is already done now.
A more simple solution would be having fixed number of search slots which can only be (de-)activated.

Concerning multiline input: Instead of horizontal scrolling in single input line there could be a vertical increase of input line (multiline input) if search string exceeds screen width.
Then complete search string is visible.

Summary:

1. I vote for moving "Cont. analysis" and "Number of threads" to submenu
2. I like both ideas: clickable elements bellow search line i.e. multiple, independent search lines which are or'ed and suggestion with multi line

Thank you for taking care: Your plugin is really a big help and simplifies analysis heavily

Frank

[svlad-90]

Hi Frank,

---

In docu I did not find hint how to access this yellow-orange view => could you give me hint how to do this?

You are right. That part is not straightforward. Here is a gif that shows how exactly to access the filters view:

=> I'll add the same to the corresponding documentation chapter in 1-2 days. Thanks for pointing that out.

---

=> Hiding these two elements is a good in any case. At least to me they do not make sense at this exposed position but it would be sufficient having them in some submenu

Ok. I'll remove them within the scope of this task.

---

=> This idea sounds great and allows having multiple search input lines which can separately be (de-)activated. By default only one search line could be active together
with a button to add an additional search line. Each element could be closable and then element would disappear. Each search line could be filled with presets from left menu as it
is already done now.
A more simple solution would be having fixed number of search slots which can only be (de-)activated.

Ok. I've got your point. Your adjustments do really make sense. But I feel that there will be still one visible additional regex input field, with the possibility to switch between the added string items.

This:

will be turned into this:

There will be an option to still use the old-style line edit. But the new one will be set as the default one.

---

I like both ideas: clickable elements bellow search line i.e. multiple, independent search lines which are or'ed and suggestion with multi line

Ok. I will try to move on with a more complex solution. It might take more time, but I think this feature worth it.

---

Thank you for taking care: Your plugin is really a big help and simplifies analysis heavily

Thank you for using it! ))

---

P.S. I'm currently busy with the refactoring in terms of the following task: #111. I'm building a simple version of the components architecture. Thus, expect this task to be started in ~2 weeks from now.

[FrankSchuehlein]

Hi Vlad,

Ok, now I managed to get the filter view. Really well hidden ;-)

But now next problem comes up: How do I enter some data? After playing around I found out that I have to enter (?<VAR_CONTROLSTATE>ccontrols) to define a variable "CONTROLSTATE" which appears then in filter view. regex is defined afterwards. But this does not shorten my search line because as soon as string is removed from search line it is also removed from filter view. I thought filter view is some kind of repository of regex and in search line you only refer to one of the variables e.g. abc := "" => in search line you only have (?<VAR_abc>) to address it

I have the impression that I still don't get feature

[svlad-90]

Hi @FrankSchuehlein,

The idea of the "filters view" is slightly different from what you expect to get from it. It is ONLY an alternative view of your regex expressions. NOT a repository or vocabulary from where you can fetch parts of the regex expressions to build a more complex one. Not like that.

The stored regex patterns within the "patterns view" is that vocabulary, which allows you to form the complex combinations of the regexes:

---

One of the examples of how I'm using the "filters view". E.g. I want to track the UI calls:

• Consider the syntax of the messages, which I want to match
• Define the variable for an application id
• Define the variable for the called IPC interface
• Define the variable for the used IPC request
• Run search
• After the search is finished, use autocompletion to set a specific application, interface, or request which I'm interested in. Or manually enter their names, if I remember them.
• Profit

In my case, I'm storing such useful regex expressions, thus each time when I'm getting back to them, the variables are instantly available. Thus, I do not need to search for important, replaceable parts of my regex. It is adjustable much easier via the "filters view", especially considering the autocompletion.

---

Hopefully, the above explanation will help you to get the meaning of this feature and you will find an area for it to be used in your daily work.

---

P.S. That does not exclude all the statements which we've discussed above. If "filters view" does not make your life easier - just wait until I'll implement the new killing feature with multiple input strings. ☺

[svlad-90]

The plugin has advanced considerably since this issue was last updated. Some of the ideas discussed previously are no longer relevant.

Let's define the scope of this task as changing the regex input from QLineEdit to QTextEdit to achieve the initial request - more comfortable working with the regex content.

The requirements for the QTextEdit:

• It should change height to fit the content.
• Maximum height - 3 rows
• Disable 'new line' input
• Replace '\n' and '\r' on the paste operation
• Adapt all other features working for the QLineEdit, such as text selection from the filters view, etc.
• Maybe some other use cases are not listed here. I'll additionally think about this while making this change.

[svlad-90]

Hi @FrankSchuehlein, this issue is finally fixed. ))

You can read about how the regex text input works now here:
https://github.com/svlad-90/DLT-Message-Analyzer/blob/master/md/search/search.md#regex-text-editor