Promised changes are in atteached patch.
1) substitution "\n" -> "|" if multiline is not switched on
2) avoid writing to column strings
The patch is against ver 0.9.13 now.
Tomas Kukosa wrote:
>
> > 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.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
Attachment:
multig13.diff.gz
Description: GNU Zip compressed data
