[protege-discussion] Unusual placement of setModified in FormWidget?

[Richard Dunlap]

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 
correctly update.

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?)

Thanks!

-- Richard Dunlap