I’m not sure, but even if they did all work, I didn’t want to be reliant on what Autodesk may expose, unexpose, rename or break in future versions.
I didn’t want to be reliant on what Autodesk may expose, unexpose, rename or break in future versions.
Fair enough
Thanks to all of you, guys !
Scenario : a rollout with a datagridview with varying rowcount and a button under the datagridview.
To resize the rollout precisely at the right height when creating/removing rows in the datagridview, you have to know the height of the datagridview and of the button.
button.height will get you an error in maxscript because there is no height property
So you have to insert a constant (button height) in your rollout height computation and thinking to change it if you change the button height in the rollout creation part.
But the real reason I would want to use pure .NET GUI is to get rid of these strange behaviors on contol editing when dealing with dotnetcontrols in a max rollout instead of dotnet objects in a dotnet form :
- some keys which are not raised by the editing control (Enter, Esc.)
- label editing validation/canceling
I think I have seen here and there in the forum that these issues don’t occur with dotnetobjects and dotnet form.
Can anybody confirm this ?