> On Mon, Jun 09, 2003 at 09:37:27AM +0200, Tomas Kukosa wrote:
> > If this feature is switched on then the "\n" character is checked in the
> > COL_PROTOCOL
> > and COL_INFO columns and the text is split into more lines. It is done
> > for GUI, printer output and tethereal output.
>
> And if the feature isn't switched on, the display looks strange if
> there's a newline in the column.
If the feature isn't switched on the "\n" can be substituted with e.g.
"|". I will change it.
> Is there any reason why that feature *shouldn't* be switched on? I.e.,
> is there any reason why it should be a preference?
Maybe, somebody preferes only one line regardless of line length.
> Unfortunately, it is not always the case that you can split the text;
> "col_set_str()" sets the column text pointer to point to the string
> supplied by the caller, rather than copying the text (this saves, as I
> remember from when I did some profiled runs, reading in large captures,
> a significant amount of CPU time), and that string might not be writable
> (and even if it *is* writable, the column code shouldn't change it, as
> it might, for example, be a string constant).
>
> I.e., "packet_list_append()" can't safely do
>
> ch = lnp[len]; lnp[len] = '\0';
>
> because "lnp" might point to a read-only portion of the address space.
I will fix it.
> > Note: there are two different possible features:
> > 1) multiline text in some columns
> > 2) multiple rows per packet
> > My patch solve the 1st feature. The 2nd feature can be implemented
> > independently and both can be used together.
>
> What is the purpose of multiline text in a column - especially in the
> Protocol column?
The purpose for of multiline text in COL_INFO is to have possibility
display longer description, message parameters, etc.
I have to profess I use multiline text in COL_PROTOCOL as a simple
replacement of the 2nd feature. But if the PDU has not its own addresses
and you need not binding between PDU row and tvb data source it is
enough.
I will try to find free time to do the 2nd feature but I can not say how
much work it is and when it can be done. It requires more changes on
other places than multiline text and new API functions will be necessary
too (at least something like
void col_new_row(column_info *col_info, tvbuff_t *tvb, gint start, gint
length) ).
> Feature 2) would probably be more cleanly implemented if it didn't
> involve newlines in columns.
The fetures 1) and 2) are independent from implementation point of view.
The question can be the visual point of view. But I think it depends on
dissectors how readable the visual output will be.
