I one morphes the selected object into another object very often some framingSpecs are lost and replaced by the default ones.

Example: ListBox and a push Button (which is placed below the ListBox) and the top-AttachmentContraint of the button is XmAttachWidget with value 5 to the ListBox. This framingSpec is totally lost, when the ListBox is morphed.

The intention of morphing is to move as much widget state to the new widget as possible. It is less clear whether the newly morphed widget stand in for the original widget when it comes to other widget's dependencies on the original widget.

This may have been a case where the original developers of the morphing option didn't consider all of the cases (or maybe they did consider this case and rejected it).

In the general case, there is no way to preserve a widget attachment to a morphed widget as you have no idea what size the morphed widget will be.

solveig wrote:In the general case, there is no way to preserve a widget attachment to a morphed widget as you have no idea what size the morphed widget will be.

I could imagine several answers, but that one was strange.

Why? Take the very common cases of morphing a listbox to a dropdown or vice versa. In each case, the new widget has a very different size than the original. Preserving a widget attachment in either case would make little sense.

marten wrote:Ok, its not a bug - because nobody knows, what the original developers wanted to do, when he invented the morphing feature ... nice answer.

Actually, we can see that this behavior is likely intentional. If you take your original example, the attachment on the button is actually modified to become a frame-based attachment during the conversion. The easiest thing for the original developer would have been to simply done nothing with any attached widgets. Instead, those attachments are actually modifed from widget-based to frame-based.