Comment # 4
on bug 11687
from Gerald Combs
(In reply to Paul Offord from comment #3)
> This is just a PoC for a tool we are working on. I've attached the code -
> what little there is. I'm not a developer and my C skills are very rusty,
> so excuse the quality.
>
> Back to the problem. There is quite a neat interface between Qt and WS. Qt
> seems to call back into WS via MainWindow::qt_static_metacall which looks
> like an API with operation codes. After entering a packet number in the GUI
> box, pressing "Go to packet" function calls the
> MainWindow::qt_static_metacall function four times with op codes 209, 49, 48
> and 49 again. I tried tracing through these but kept ending up back in the
> Qt code. So I took a different tack.
Tracing through qt_static_metacall usually means you're deep in the bowels of
automatically generated signal/slot code.
> After wandering through the code for more time than I should have I found
> PacketList::selectionChanged - I think this is the function that updates the
> packet detail. When you do a Go to packet through the GUI this code gets
> called. When I use plugin_if_goto_frame this function isn't called.
>
> All that said, it's strange that you can't recreate the problem.
MainWindow::plugin_if_mainwindow_gotoframe and MainWindow::on_goToGo_clicked
both call MainWindow::gotoFrame[1], which calls PacketList::goToPacket, which
calls PacketList::setCurrentIndex, which *should* trigger a call to
selectionChanged.
Can you try adding a call to drawCurrentPacket just after setCurrentIndex in
PacketList::goToPacket? That will force a deselection and reselection.
[1] Note that we have a member function named "gotoFrame" which selects a
packet by number and a UI element named "goToFrame" which is a subclass of
AccordionFrame. We should probably rename the member function.
You are receiving this mail because:
- You are watching all bug changes.
