CWForm sizing troubles
2 views
Skip to first unread message
Richard Sargent
Jul 6, 2026, 5:49:49 PM (10 hours ago) Jul 6
to VAST Community Forum
I have been working on a browser extension, so I am working with Common Widgets and Motif rules.
I have tried laying out a small form comprising a couple of widgets (a label on the left and a combo box beside it). The horizontal sizing and spacing works exactly as I want and expect.
But the vertical aspects are driving me around the bend. I set the top as inset 30 from the enclosing form (XmATTACHFORM 30) and the bottom inset 55 from the enclosing form's top (XmATTACHOPPOSITEFORM -55, per the rules.)
The problem is that VAST concludes the height should be 85 rather than 25. The CwFormConstraints think the height should be 21. I don't agree with that, but it's hardly the big problem. 85 is a problem. It causes this form to overlay the two below it in the layout, one at 60 inset from the enclosing form and one at 90 inset.
This overlaying prevents one from clicking on or into a toggle or text field and sometimes, seemingly depending on whim, hides some or all of the lower widgets.
I hacked CwFormConstraints and CwWidget, etc. to report information about what they think. The screen shot shows red highlights on relevant things. It looks like the constraints pretty much agree with me and my wishes. But, the form has numbers apparently pulled by some random algorithm. Actually, it is consistent. If I vary the numbers, I get a corresponding result.
It's as if the top inset is added to the bottom inset to come up with a fictitious total.
I cannot compass that such a thing could have existing in VA the nearly four decades of the software's lifespan. But, I can't imaging it is a recently introduced anomaly.
If anyone can explain this behaviour, I would be grateful.
But the vertical aspects are driving me around the bend. I set the top as inset 30 from the enclosing form (XmATTACHFORM 30) and the bottom inset 55 from the enclosing form's top (XmATTACHOPPOSITEFORM -55, per the rules.)
The problem is that VAST concludes the height should be 85 rather than 25. The CwFormConstraints think the height should be 21. I don't agree with that, but it's hardly the big problem. 85 is a problem. It causes this form to overlay the two below it in the layout, one at 60 inset from the enclosing form and one at 90 inset.
This overlaying prevents one from clicking on or into a toggle or text field and sometimes, seemingly depending on whim, hides some or all of the lower widgets.
I hacked CwFormConstraints and CwWidget, etc. to report information about what they think. The screen shot shows red highlights on relevant things. It looks like the constraints pretty much agree with me and my wishes. But, the form has numbers apparently pulled by some random algorithm. Actually, it is consistent. If I vary the numbers, I get a corresponding result.
It's as if the top inset is added to the bottom inset to come up with a fictitious total.
I cannot compass that such a thing could have existing in VA the nearly four decades of the software's lifespan. But, I can't imaging it is a recently introduced anomaly.
If anyone can explain this behaviour, I would be grateful.
Reply all
Reply to author
Forward
0 new messages