Ethereal sometimes creates a progress dialog bar and then, if
the processing is fast, quickly destroys it. The resulting
"flash" can be disconcerting. This set of patches ensures a
progress bar is either not created or is displayed for a minimum
time.
svn path=/trunk/; revision=5916
an "err" argument that points to an "int" into which to put an error
code if it fails.
Check for errors in one call to it, and note that we should do so in
other places.
In the "wtap_seek_read()" call in the TCP graphing code, don't overwrite
"cfile.pseudo_header", and make the buffer into which we read the data
WTAP_MAX_PACKET_SIZE bytes, as it should be.
In some of the file readers for text files, check for errors from the
"parse the record header" and "parse the hex dump" routines when reading
sequentially.
In "csids_seek_read()", fix some calls to "file_error()" to check the
error on the random stream (that being what we're reading).
svn path=/trunk/; revision=4874
"epan/..." pathnames, so as to avoid collisions with header files in any
of the directories in which we look (e.g., "proto.h", as some other
package has its own "proto.h" file which it installs in the top-level
include directory).
Don't add "-I" flags to search "epan", as that's no longer necessary
(and we want includes of "epan" headers to fail if the "epan/" is left
out, so that we don't re-introduce includes lacking "epan/").
svn path=/trunk/; revision=4586
Gerald's fix wasn't the real problem; the original code was wrong in
treating a GNode containing a ph_stats_node_t as a GNode that is part
of a proto_tree; it worked because of the coincidental layout of the
two structs.
Now the code has been fixed, and some macros have been added for
accessing the GNodes and some variables renamed so that the code
is clearer.
svn path=/trunk/; revision=4464
Put a hash-table of "interesting" fields in the per-proto-tree data.
The dfilter code records which fields/protocols are "interesting" (by which
I mean, their value or existence is checked). Thus, the proto_tree routines
can create special arrays of field_info*'s that are ready for the dfilter
engine to use during a filter operation.
Also store the "proto_tree_is_visible" boolean, renamed "visible", in
the per-proto-tree data.
Move epan_dissect_t to its own header file to make #include dependencies
easier to handle.
Provide epan_dissect_fill_in_columns(), which accepts just the epan_dissect_t*
as an argument.
epan_dissect_new() needs to be followed by epan_dissect_run() for the
dissection to actually take place. Between those two calls,
epan_dissect_prime_dfilter() can be run 0, 1, or multiple times in order to
prime the empty proto_tree with the "intersesting" fields from the dfilter_t.
svn path=/trunk/; revision=4422
display representation should be put into protocol tree items if a
protocol tree is to be constructed; have it set "proto_tree_is_visible"
from that argument.
svn path=/trunk/; revision=4408
structure to the "packet_info" structure; only stuff that's permanently
stored with each frame should be in the "frame_data" structure, and the
"column_info" structure is not guaranteed to hold the column values for
that frame at all times - it was only in the "frame_data" structure so
that it could be passed to dissectors, and, as all dissectors are now
passed a pointer to a "packet_info" structure, it could just as well be
put in the "packet_info" structure.
That saves memory, by shrinking the "frame_data" structure (there's one
of those per frame), and also lets us clean up the code a bit.
svn path=/trunk/; revision=4370
already contain a pointer to an epan_dissect_t, which contains
the proto_tree.
Routines calling epan_dissect_new() do not create their own
proto_tree via proto_tree_create_root(); instead, they pass a boolean
to epan_dissect_new() telling it whether it should create the root
proto_tree.
svn path=/trunk/; revision=4343
as, on a large capture, it could take a significant amount of time.
Let the user stop the computation and, if they do, don't pop up the
statistics dialog box.
Create a new header file declaring the routines to create, update, and
destroy progress dialog boxes; those routines' APIs don't depend on
GTK+, but others declared in "ui_util.h" do, and we don't want to oblige
a source file to depend on GTK+ headers unless it uses a GTK+ API or an
API that depends on GTK+.
svn path=/trunk/; revision=3179
organizes the protocols in the same hierarchical order in which
they are found in the packet.
The GUI needs some more refinement (placment of vertical
scrollbar, style of GtkCTree, initial sizing of window).
I need to add an option to honor/not honor the current display filter.
svn path=/trunk/; revision=3162