add two new callbacks:

cf_cb_file_closing (called before closing a capture file) cf_cb_file_closed will be called afterwards, but both only if a file is really closed as cf_close is called more often ...

If we are closing large capture files (~20MB), the screen looks ugly while the file is closed. Change this so the screen will immediately go back to initial state and a dialog (without buttons) is shown that the file is currently closed. As the operation which takes most of the time to close the file is a single eth_clist_clear call, we can't use a progress bar here.

cf_cb_live_capture_stopping: called when the user wants to stop the capture (toolbar or menu clicked). At least on Win32, the time between this and the actual stop completed can be noticeable (1-2 seconds), so the user doesn't know if the button press did anything at all. Do something similar as above, show a dialog box without buttons to inform that the close is in progress.

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@15891 f5534014-38df-0310-8fa8-9805f1628bb7

1 files changed, 3 insertions, 0 deletions

diff --git a/capture.c b/capture.c
index 12f9cbe3f3..c89feea5f9 100644
--- a/capture.c
+++ b/capture.c
@@ -119,6 +119,8 @@ capture_stop(capture_options *capture_opts)
 {
   g_log(LOG_DOMAIN_CAPTURE, G_LOG_LEVEL_MESSAGE, "Capture Stop ...");
 
+  cf_callback_invoke(cf_cb_live_capture_stopping, capture_opts);
+
   /* stop the capture child gracefully */
   sync_pipe_stop(capture_opts);
 }
@@ -310,6 +312,7 @@ capture_input_new_packets(capture_options *capture_opts, int to_read)
 
          XXX - abort on a read error? */
          cf_callback_invoke(cf_cb_live_capture_update_continue, capture_opts->cf);
+		 /* update the main window, so we get events (e.g. from the stop toolbar button) */
          main_window_update();
       break;