Fix a nasty side-effect of running the packet list in
authorguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Mon, 3 Jan 2000 03:46:36 +0000 (03:46 +0000)
committerguy <guy@f5534014-38df-0310-8fa8-9805f1628bb7>
Mon, 3 Jan 2000 03:46:36 +0000 (03:46 +0000)
commit3ffba65d6b5de013abb6d6f8a426af4041be398d
treeb4dc19458df1d5a9d8eb084b64f509b31e3ade8a
parent296a0be359863892dfda7142673c8b395452d700
Fix a nasty side-effect of running the packet list in
GTK_SELECTION_BROWSE mode - that mode apparently always arranges that
there is (in a non-empty GtkCList) one row selected, which means that
when the first row is added, it selects it.

Unfortunately, that causes a "select-row" signal to be emitted, which
causes "select_packet()" to be called - but we haven't yet set "fd->row"
for the frame we're adding, so "select_packet()" can't find the frame
for the row being selected, and it aborts.

This causes a core dump when the first packet arrives during an "Update
list of packets in real time" capture.

For now, we handle this by, if we don't find the frame with the given
row number, checking that there's exactly one frame in our list of
frames and, if so, saying that frame is the frame for which we're
looking.

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