[Octave-bug-tracker] [bug #53443] Variable Editor: openvar VAR should show the tab on which the variable editor is

[Dan Sebald]

Follow-up Comment #18, bug #53443 (project octave):

Oh.  Yeah, that doesn't appear to work.  I've printed out


    for (int i=0; i < tbar->count (); i++)
      {
std::cerr << "void* cast: " << tbar->tabData(i).value<void*> () << "\n";
        if (tbar->tabData(i).value<void*> () == this)
          {
std::cerr << "FOUND THE ONE\n";
            tbar->setCurrentIndex (i);
            return;
          }
      }


which results in


>> x = magic(5);
>> openvar x;
>> void* cast: 0
void* cast: 0
void* cast: 0
void* cast: 0
void* cast: 0
void* cast: 0


>From the documentation:

http://doc.qt.io/qt-5/qvariant.html#value

"Returns the stored value converted to the template type T. Call canConvert()
to find out whether a type can be converted. If the value cannot be converted,
a default-constructed value will be returned."

It's returning a value of 0 (the default) because Qt isn't allowing that type
of conversion.  Generally, from the looks of it, Qt doesn't like values being
converted to pointers.

With that in mind, I think what I had in the changeset of Comment #11 is
probably the most sound.  Converting a pointer to a ULongLong QVariant is
probably not considered bad by Qt.  Somehow Qt must be doing that kind of
thing in the QTabBar code when a new widget is added, and what I've done is
likely how Qt developers have done it.

Now, given what I printed out--i.e., that the value<void*> is producing 0--one
would think that the webinfo::current_tab_changed() routine would crash. 
However, I don't see anywhere in the code where this object is actually
instantiated so don't know where to look to test it.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53443>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/