Wireshark-dev: Re: [Wireshark-dev] VoIP Calls and -Graph dialog behaviour
From: "Jim Young" <[email protected]>
Date: Sun, 18 Oct 2009 18:47:13 -0400
Hello Lars/Anders,

>> [] On Behalf Of RUOFF LARS
>> Sent: den 14 oktober 2009 15:48
>> I have attached a patch for dlg-utils.c which removes the transient
>> thing for WIN32 only.

> "Anders Broman" <> 10/14/2009 11:03 AM >>>
> Hi,
> I've done some quick tests with your patch closing wireshark 
> with a consol window
> The child windows remain and dissaperes when the consol window 
> is closed. If you
> Try to close the child window it will not close, closing the console
> closes the hanging window. 
> I don't get the strange grafical artifacts I used to have(or that hapend
> in diferent circumstances). 
> With no console all windows close.
> I'm not sure about the best aproach here...

While Lar's patch [1] to gtk/dlg-utils.c may not completely 
solve all the issues on WIN32 associated with having a 
console window open when exiting Wireshark, the patch 
in its current form appears to resolve at least two other 
issues I've recently experienced on WIN32 machines.

WIN32 Issue 1.  

Some Wireshark interactions result in the creation of 
a temporary progress dialog window (gtk/progess_dlg.c). 
When the progress window is eventually destroyed the 
focus does NOT always revert back to the window that 
originally had focus but instead the focus is moved to 
Wireshark's main window.  

One example of this behavior is with the Statistics | TCP 
Stream Graph feature.  The TCP Stream Graph feature 
creates two new windows: a TCP Graph window and 
a Control window.  The Control window includes a 
"Graph type" page that can be used to select the type 
of graph displayed within the TCP Graph window.   If 
you have a "big enough" TCP trace (for example where 
the selected the TCP session represents 50MB of TCP 
data) then when you use the Graph type Radio buttons 
to switch back and forth between the "Throughput" 
graph and any of the other three graph types a temporary 
progress dialog will appears that displays the text 
"Processing...".  When this progress dialog is destroyed 
focus will have moved from the Graph window to 
Wireshark's main window.  

With Lar's patch applied, when the progress dialog is 
destroyed the focus appears to return to the window 
that last had focus prior to when the progress dialog 
was created.

WIN32 Issue 2. 

If you have enabled the use of the Console window
(Always (debugging)) and have opened up a TCP Stream 
Graph but you attempt to shutdown Wireshark from the 
Wireshark main window without first closing the TCP 
Stream Graph windows then the entire MS WIN32 system 
can get extremely sluggish and erratic and it can be 
very difficult to get focus back to Wireshark's Console 
window.  If you can manage to get focus to the Wireshark
Console window then any key-press WILL destroy all of 
the orphaned/non-responsive Wireshark windows and 
the system will settle back to normal WIN32 behavior.

With Lar's patch applied the sluggishness and erratic 
behavior caused by closing Wireshark's main window
while the TCP Stream Graph windows are still open 
does NOT occur.  Of course there will still be two 
"non-responsive" TCP Stream Graph related windows 
present, but when focus is changed to the Console 
window and any key is pressed all three windows will 
be destroyed.


In addition to applying Lar's patch, I think a more 
complete WIN32 solution to the problem of the 
unresponsive windows on Wireshark shutdown would 
be to enumerate and explicitly "hide" (or perhaps even 
destroy) of any and all Wireshark windows (with the 
exception of the Console window itself) prior to the 
call to destroy_console().

Within gtk/main.c there is already _WIN32 specific 
code to hide Wireshark's main window with a call
"gtk_widget_hide(top_level)" prior to the 
WSACleanup() and destroy_console() calls.

Perhaps a new (WIN32) specific function could be 
developed using gtk_window_list_toplevels() [2] 
to hide any displayed windows just prior to the 
WSACleanup() and destroy_console() calls.  

FWIW:  I made one simplistic hack with good effect 
where I hid the two TCP Stream Graph Windows (the 
g->toplevel and g->gui.control_panel windows) at 
Wireshark shutdown.  My hack was simply for 
proof-of-concept purposes.  It used a global to 
store the last "struct graph" item to allow one to
(indirectly) find and hide the two TCP Stream 
Graph windows.   My particular proof-of-concept 
hack did not attempt to account for the fact that 
the TCP Stream Graph feature can be concurrently 
enabled more than once and therefore there 
may be more than one "struct graph" item in play.

I hope you find this info useful.

Jim Y.

[1] http://www.wireshark.org/lists/wireshark-dev/200910/msg00147.html 
[2] http://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-window-list-toplevels