wireshark/gtk/filter_prefs.h

50 lines
1.8 KiB
C
Raw Normal View History

/* filter_prefs.h
* Definitions for dialog boxes for filter editing
* (This used to be a notebook page under "Preferences", hence the
* "prefs" in the file name.)
*
* $Id: filter_prefs.h,v 1.15 2003/01/15 05:58:50 guy Exp $
*
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@ethereal.com>
* Copyright 1998 Gerald Combs
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#ifndef __FILTER_H__
#define __FILTER_H__
In the process of destroying a filter editing dialog box, we get a selection change event on the list of filters. Unfortunately, this can happen after some other widgets in that dialog box have already been destroyed - including some of the widgets that such a selection change event can change. This sometimes happened when "filter_prefs_delete()" hadn't been called, so the mechanism we had been using, with a Boolean datum attached to the dialog box, set in "filter_prefs_delete()" before we actually destroy the dialog box, wasn't sufficient to keep that from happening. Attach to the top-level window data items containing pointers to the widgets changed when a filter is selected from the list, give each of those widgets their own destroy callbacks, clear the pointer attached to the top-level widget when the widget is destroyed, and don't do anything to the widget when a filter is selected from the list if the pointer for that widget is null, as that means the widget's been destroyed and we *can't* do anything to it. Not all filter editing dialogs created on behalf of a "Filter:" button next to a text entry box should, when you click "OK", activate the text entry box; if the text entry box is part of a dialog box with multiple widgets, the user might not have filled in all of the items in that dialog box, so you shouldn't activate it for them. Add a mechanism by which, when creating a filter editing dialog box, you can specify whether the "OK" button should just fill in the text entry box or should fill it in and also activate it. svn path=/trunk/; revision=2922
2001-01-21 01:45:07 +00:00
/*
* Structure giving properties of the filter editing dialog box to be
* created.
*/
typedef struct {
gchar *title; /* title of dialog box */
In the process of destroying a filter editing dialog box, we get a selection change event on the list of filters. Unfortunately, this can happen after some other widgets in that dialog box have already been destroyed - including some of the widgets that such a selection change event can change. This sometimes happened when "filter_prefs_delete()" hadn't been called, so the mechanism we had been using, with a Boolean datum attached to the dialog box, set in "filter_prefs_delete()" before we actually destroy the dialog box, wasn't sufficient to keep that from happening. Attach to the top-level window data items containing pointers to the widgets changed when a filter is selected from the list, give each of those widgets their own destroy callbacks, clear the pointer attached to the top-level widget when the widget is destroyed, and don't do anything to the widget when a filter is selected from the list if the pointer for that widget is null, as that means the widget's been destroyed and we *can't* do anything to it. Not all filter editing dialogs created on behalf of a "Filter:" button next to a text entry box should, when you click "OK", activate the text entry box; if the text entry box is part of a dialog box with multiple widgets, the user might not have filled in all of the items in that dialog box, so you shouldn't activate it for them. Add a mechanism by which, when creating a filter editing dialog box, you can specify whether the "OK" button should just fill in the text entry box or should fill it in and also activate it. svn path=/trunk/; revision=2922
2001-01-21 01:45:07 +00:00
gboolean wants_apply_button; /* if it should have an Apply button */
gboolean activate_on_ok; /* if parent text widget should be
activated on "Ok" or "Apply" */
} construct_args_t;
void capture_filter_construct_cb(GtkWidget *w, gpointer user_data);
void display_filter_construct_cb(GtkWidget *w, gpointer construct_args_ptr);
void filter_button_destroy_cb(GtkWidget *button, gpointer user_data);
void cfilter_dialog_cb(GtkWidget *w);
void dfilter_dialog_cb(GtkWidget *w);
Split "filter_dialog_cb()" into "filter_dialog_cb()", which pops up a "global" dialog box when "Edit:Filters" is selected, so that the list of filters can be edited, and "filter_browse_cb()", which pops up a dialog box associated with a "Filter:" button and a text entry widget attached to that button, so that a filter can be selected or saved (although it also supports the same editing that the "global" dialog box does). Have "filter_dialog_cb()" connect the window in which the "Filter:" button lives and the filter dialog box, so that: if the window in which the "Filter:" button lives goes away, so does the filter dialog box (as it no longer has a text widget into which it can stuff the selected filter); if the "Filter:" button is clicked when there's already a filter dialog box open, we just reactivate that existing dialog box rather than popping up a new one. Also keep a pointer to the "global" filter dialog box, so that we also arrange that there's only one of them (by reactivating the existing on if "Edit:Filters" is selected when there's already a "global" filter dialog box open). Keep around pointers to the dialog boxes that contain the "Filter:" buttons, so that we can arrange that there be only one of them (that was a side-effect of an earlier attempt at fixing the problems described above, but it's still useful for keeping multiple competing dialog boxes from being open - there's more of that to be done). Make the pointer to the "Open Capture File" dialog box widget static to "file_dlg.c" - nobody outside of "file_dlg.c cares about it. svn path=/trunk/; revision=1774
2000-04-01 12:03:42 +00:00
#define E_FILT_TE_PTR_KEY "filter_te_ptr"
#endif /* filter.h */