Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Add expression dialog, proposal for some changes

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Sat, 6 Mar 2004 23:59:56 +0100
From: Ulf Lamping

| Olivier Biot wrote:
|
| >From: Ulf Lamping
| >
| >| 3) replace the relation list by a set of radio buttons,
insensitive
| >the
| >| ones not suitable for the current field type
| >
| >Beware: some operators only operate on slices, so from the moment
one
| >ft_can_slice() returns true those operators have to be available
from
| >the moment that a (valid) slice has been entered.
| >
| >
| This should be already done if I understand the code correct,

Indeed. However when I introduced the bitwise_and operator some days
ago, because I implemented it for slices, it would *always* be
available, even when no slice was specified.

| BTW: What *is* meant be a slice here?

A slice is a data subset of a protocol or protocol field. Typically, a
slice consists of a start byte offset and a byte length, or a start
byte offset and an end byte offset.

| >| 5) add a column of field type labels (Boolean, unsigned 2 bytes,
| >...),
| >| with only the field type corresponding to the field name
sensitive
| >and
| >| all other insensitive
| >
| >Beware: the field type and its length are not always fixed. For
| >example FT_BYTES and FT_STRING don't have a fixed length.
| >
| >
| I only wanted to have labels for all posible types, and the label of
the
| type corresponding to the
| currently selected field not grayed out so (Boolean, Signed Int 32
bits,
| Unsigned Int 8 bits, String, ...),
| corresponding to the FT_x types.
| Don't wanted to show the length at my first thoughts, although this
| might be a good thing to have also,
| but let's think about that later.
|
| >| 6) add a field at the bottom of the dialog, showing the resulting
| >filter
| >| string
| >
| >Definitely! Maybe even a multi-line field.
| >
| >One remark: should we provide length/size operators to the dfilter
| >language?
| >
| >
| >
| Sorry, don't understand. What do you mean by that?

We cannot test for the length of a protocol item or protocol field
item today, unless a length field exists for the data. It would e.g.,
be interesting to be able to filter on "length(FOO) > 5". That's
probably something we should discuss in another mail thread.

Regards,

Olivier