Search Mailing List Archives
[protege-discussion] Unusual placement of setModified in FormWidget?
rdunlap at asinc.com
Tue Nov 28 10:48:55 PST 2006
In Protege 3.1, using a modified version of the TemplateSlotsWidget that
handles subslots of :DIRECT-TEMPLATE-SLOTS (which I will send along once
I push it through the right administrative channels, whenever that is),
I experienced the following interesting behavior.
* After creating a class, a subclass with additional slots, and an
instance of the subclass, addition or deletion of slots from the
subclass failed to update the form layout correctly. Specifically, all
slots were placed in one column and there was an overlap of widgets for
one slot from the base class and one slot from the subclass at the top
of the column.
* After removing the instance, the next add/remove caused the layout to
I have not been able to replicate this behavior with the
TemplateSlotsWidget. I suspect that this has to do with the fact that
my modified widget uses the get/setValues and valueChanged interfaces
for handling updates, while the TemplateSlotsWidget in 3.1 interacts
directly with the knowledge base.
Through some detective work, I found that the class form layout was
being incorrectly updated with all subclass components being left at
(0,0) -- the final layout was due to the sanity check, and this
apparently happened when the instance reconstituted the form during its
update. Moving the setModified call in FormWidget.layoutLikeCls from
the middle of the method to the end of the method (most significantly, I
believe, *after* the createWidgets call) causes the Instance form update
to be postponed until after the Class form update had a chance to
complete the new layout correctly.
The key question: is there a reason for the setModified call to come
earlier in the method? (In other words, have I broken something else?)
-- Richard Dunlap
More information about the protege-discussion