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.
Comment:
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
