Wireshark mailing list archives
Re: VoIP Calls and -Graph dialog behaviour
From: "Jim Young" <sysjhy () langate gsu edu>
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. 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: VoIP Calls and -Graph dialog behaviour, (continued)
- Re: VoIP Calls and -Graph dialog behaviour Anders Broman (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour Jaap Keuter (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour RUOFF LARS (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour Anders Broman (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour Jaap Keuter (Oct 22)
- Re: VoIP Calls and -Graph dialog behaviour Anders Broman (Oct 22)
- Re: VoIP Calls and -Graph dialog behaviour Jaap Keuter (Oct 22)
- Re: VoIP Calls and -Graph dialog behaviour RUOFF LARS (Oct 22)
- Re: VoIP Calls and -Graph dialog behaviour Anders Broman (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour RUOFF LARS (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour Anders Broman (Oct 14)
- Re: VoIP Calls and -Graph dialog behaviour Jim Young (Oct 18)