[Octave-bug-tracker] [bug #47585] GUI editor does not show already active breakpoints when a file is opened

[Dan Sebald]

Follow-up Comment #13, bug #47585 (project octave):

The changeset appears to work on a little testfun() I wrote, placed
breakpoints (command line and point/click), closed and opened.  The approach
is the way to go, as I see it.  A couple things to keep in mind that may be of
importance but aren't so significant because they are easily rectified at a
later time.

1) Qt-related: Make sure there is a uniqueness to the information being sent
back and forth asynchronously (via the signal/slots mechanism) so that the GUI
doesn't get confused by multiple objects requesting information.  E.g., say
multiple files are all opened at one time and they all request breakpoint
info.  Is it possible that information requested about one file could end up
going to some other file?  The way I had addressed this was quite simple: tag
the command using the object's "this" pointer as an ID then when the
information comes back through the slot check that the ID-tag matches "this".

2) More general: Is the "emit argout_signal (argout);" placed in the code at a
location where it is Qt related and not more general interface or core code? 
That is, this concept of calling a command for information would hold for
other third-party frameworks so long as the interface allowed it.  So it would
be nice if this weren't restricted to, say, this Qt implementation only.  I
think that aspect of it can be cleaned up later without too much change to
where you placed the "emit"--need some thread considerations and such, but
still not too bad.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?47585>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/