only return file types that could handle a single file with all those
encapsulations - this means that
1) if there's more then one encapsulation, the file format has
to handle per-packet encapsulation;
2) just because a file format handles per-packet encapsulation,
that doesn't mean that it can handle the *particular* encapsulations
being handed to it.
This fixes some cases where we were claiming that a file could be saved
in a format that doesn't actually support it (e.g., ISDN files being
reported as savable in pcap-NG format - there's no LINKTYPE_ value for
ISDN including B and D channels).
svn path=/trunk/; revision=43300
out of main_menubar.c into routines in main.c.
Move some routines that are only used by main.c into
main_menubar_private.h.
svn path=/trunk/; revision=43298
it specifically works on the main window's tree and hex dump views (it
doesn't apply to packet windows - they are always showing data from a
particular packet), and move its declaration to main_packet_panes.h.
svn path=/trunk/; revision=43293
panes to main_packet_panes.c.
Rename main_tree_view_new() to proto_tree_view_new() - it's not just for
creating the main window's protocol tree view, it's also for creating
protocol tree views in packet windows.
svn path=/trunk/; revision=43292
used for popped-up packet windows, and it includes more than just code
to draw the protocol tree - it includes the hex dump pane code as well.
Rename it packet_panes.c; the stuff specific to the main window should
be moved into a different file.
svn path=/trunk/; revision=43291
used for popped-up packet windows, and it includes more than just code
to draw the protocol tree - it includes the hex dump pane code as well.
Rename it packet_panes.c; the stuff specific to the main window should
be moved into a different file.
svn path=/trunk/; revision=43290
Show all of them in the summary dialog; we will be using it in the
future to figure out what capture file formats we can write to (just
because a capture file format supports per-packet encapsulations, that
doesn't mean that it supports *all possible* encapsulations).
svn path=/trunk/; revision=43278
highlight_field() is also called when we open packet in new window and we click some bytes,
it caused redrawing packet details in *main window* but with protocol tree from (possibly) another frame.
svn path=/trunk/; revision=43277
stopped - there's no guaranteed way to make the UI's close button
inactive (on X11, it depends on whether the window manager allows that),
but we can just do nothing and return TRUE from the delete event handler
to ignore the delete event.
svn path=/trunk/; revision=43252
capture to stop, so that we don't try to quit while we're in the middle
of quitting or try to stop or restart the capture we're in the middle of
stopping.
svn path=/trunk/; revision=43250
the main loop until we're done reading the captured packets. Hopefully
this clears up bug 7318 in Evan Huus's case; I can't reproduce that
myself.
svn path=/trunk/; revision=43248
File name preferences are basically just string preferences except that the
GUI will present a "Browse" button that allows the user to go and find the
file s/he wants (rather than having to blindly type in the full path).
svn path=/trunk/; revision=43228
When building current data for packet details treeview we store two things.
- Generated string with item label
- Pointer to node field_info structure
After epan_dissect_{free, cleanup} pointer to field_info node is no longer
valid so we should clear GtkTreeStore before freeing.
svn path=/trunk/; revision=43188
(Before checking the code it wasn't clear to me what COUNT(*) was counting
and--especially with SCTP's bundling of user messages--counting fields was
really what I wanted/needed.)
Remove a 32-bit cast (should have been part of r43136).
svn path=/trunk/; revision=43137
just tweak the elements in the capture_file structure as necessary and
poke the UI to update stuff such as the windows title.
If we do a Save or Save As with a copy, don't reread the capture file,
just close the old wtap, open a wtap for the copy, and tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title.
Otherwise, don't do a full read-and-dissect pass on the capture file,
just close the old wtap, open a wtap for the new file, tweak the
elements in the capture_file structure as necessary and poke the UI to
update stuff such as the windows title, and rescan the file to update
the packet offsets (and cause Wiretap to regenerate, for a gzipped file,
the information needed to support fast random access to the gzipped
file).
This should speed up Save and Save As a bit, as well as removing some
glitches in the UI (e.g., you won't see the packet list disappear and
reappear).
svn path=/trunk/; revision=43101
"export specified packets". For "failed", let the user try again with a
different file, in case it failed due to, for example, running out of
space or quota (probably the most likely failure mode for writing, and
trying to a different volume might be the best workaround). For "user
stopped it", presumably they don't want to try again (the most likely
reason is "it was taking too damn long").
Put "Exporting to: ...", not "Saving: ..." in the statusbar if we're
doing "export specified packets".
In process_specified_packets(), allow a null range pointer to be
specified, meaning "save 'em all"; that avoids the possibly-expensive
(with a large capture) operation of initializing the range.
If a "safe save" atop an existing file fails or is stopped, get rid of
the temporary file we created.
svn path=/trunk/; revision=43095
statistics window.
Get rid of the non-modal version (it's not being used any more), and
remove the now-redundant _modal from the modal version.
svn path=/trunk/; revision=43081
really don't belong here - they have nothing to do with capture files).
Absorb the test for the target file's existence into
file_target_exist_ui().
svn path=/trunk/; revision=43077
Windows file dialog, which has its own built-in version of the "do you
want to overwrite that file?" dialog, and Notepad and WordPad, at least,
just appear to error out if you try to overwrite a file with the
read-only flag set, rather than asking whether you want to override
that.
svn path=/trunk/; revision=43072
As..." code path.
Extract the code for the "do you want to overwrite this file" and "OK,
you do - are you aware it's {user-immutable, read-only}?" code paths
into a common routine for use by both of those and, potentially, other
save/export/etc. code paths in the future.
For "Save As", allow us to save atop the current capture file, as that's
just what "Save" does if there are unsaved changes, and "safe save"
makes that work. *Don't* allow that for "Export Selected Packets
As...", however.
The file chooser is run as a modal dialog, so we don't need to worry
about creating more than one of them or about the number of marked
packets etc. being changed out from under us. Get rid of a bunch of
static variables.
svn path=/trunk/; revision=43060
live capture" and colorization, so that the ones in main_menubar.c don't
have to know about anything other than the main menubar.
Move some toolbar routines that should only be used by routines in
main.c into a main_toolbar_private.h header.
svn path=/trunk/; revision=43053
