Very nice!
However there's still a built-in hard-coded limit on the size of a filter
string. Try for instance filtering out a dozen of TCP streams, and your
filter string will be truncated at some point, resulting in a dfilter
compile error. Maybe we want to get rid of the fixed-length buffer and go to
a dynamically allocated buffer (this may require the creation of an own text
input widget, capturing keyboard input events and reallocating a new buffer
whenever the previous buffer is full)?
Regards,
Olivier
| -----Original Message-----
| From: Ulf Lamping
|
| Hi List!
|
| I've done some substantial changes in the filter editing GUI parts.
|
| a) changed the edit behaviour in the filter dialogs
| b) added a syntax check feature to the filter string text field
| c) added the "Add Expression" button to the filter toolbar
|
| a) as the former behaviour when editing a filter string was
| really crude,
| I tried to make it better. New behaviour:
|
| buttons:
| "New" will add a new field to the filter list, using the
| current values from the text entries
| "Delete" will remove the filter selected in the filter list
|
| the buttons "Copy" and "Change" are removed, as they are now
| longer necessary.
|
| When editing the text entries and some filter is selected,
| the changes will immediately
| take effect on the filter too.
|
| Also when editing the filter string field, the background
| color will become red or green, depending
| on the correct syntax of the filter string.
|
| I hope this is much more intuitive than the former behaviour :-)
|
| b) Added the same syntax check from the filter dialog also to
| the filter toolbar text entry
|
| c) Added the "Add Expression" button to the filter toolbar
|
|
| The thing left to do is using a multicolumn view (showing the
| name*and* the string) like in the color rules dialog,
| instead of a single list view (showing the name only)
| currently used in the filter dialog.
