Hello, I like to use Visual Maxscript to help quickly set up a UI. In my new copy of 2010, I am getting something very strange that is a big pain to work around every time. If I make a rollout and edit it in Visual Maxscript, when I save and close (update the script) it adds the last bit of each line between each line which seems to serve no useful purpose whatsoever. Very annoying to have to go back through and delete them all!! Does anyone know what I am doing wrong? How can I avoid this?
EXAMPLE: if I make a rollout and update it, my script looks like:
rollout unnamedRollout "Untitled" width:162 height:300
(
GroupBox grp6 "GroupBox" pos:[27,29] width:119 height:222
222
radiobuttons rdo1 "RadioButtons" pos:[39,54] width:103 height:30
30
checkbox chk1 "Checkbox" pos:[69,97] width:31 height:23 checked:true
true
)
This gets very aggravating on a rollout with dozens of controls, to go back through and delete this nonsense. Please help!
Weird. Well report it as a bug. I doubt anyone tested the visual maxscript editor during the beta.
thanks for the quick reply. On the plus side, it doesn’t seem to delete the last line after the rollout anymore. :shrug:
The visual maxscript editor, is next to unusable! You’d be better of learning how to layout the controls manually, in the end it will save you time, and you’re going to be a lot more flexible then al those position based controls.
rollout roTest "Rollout test"
(
local yOffset = -3
local xOffset = 2
local btnHeight = 18
group "groupTest"
(
button btnTest1 "1" width:51 height:btnHeight offset:[-xOffset,yOffset] across:2
button btnTest2 "2" width:51 height:btnHeight offset:[xOffset,yOffset]
)
group "groupTest2"
(
button btnTest3 "3" width:33 height:btnHeight offset:[-xOffset,yOffset] across:3
button btnTest4 "4" width:33 height:btnHeight offset:[0,yOffset]
button btnTest5 "5" width:33 height:btnHeight offset:[xOffset,yOffset]
)
)
createDialog roTest width:120
Consider that code and run it. Now change the local btnHeight = 50 and run it again. Now try to image doing that in the visual MXS editor. The UI’s will be more readable, more custumizable, you can easily swap the 2 groups on top of each other. Nothing using absolute positions, that makes it a lot more flexible.
-Johan
Taking it just a bit further
try(destroyDialog roTest)catch()
rollout roTest "Rollout test"
(
local xWidth = 250
local yOffset = -3
local xOffset = 2
local btnHeight = 20
group "groupTest"
(
button btnTest1 "1" width:(xWidth/2-9) height:btnHeight offset:[-xOffset,yOffset] across:2
button btnTest2 "2" width:(xWidth/2-9) height:btnHeight offset:[xOffset,yOffset]
)
group "groupTest2"
(
button btnTest3 "3" width:(xWidth/3-7) height:btnHeight offset:[-xOffset,yOffset] across:3
button btnTest4 "4" width:(xWidth/3-7) height:btnHeight offset:[0,yOffset]
button btnTest5 "5" width:(xWidth/3-7) height:btnHeight offset:[xOffset,yOffset]
)
)
createDialog roTest width:250
Now the buttons scale with the width of the rollout, change the xWidth = 250 paramater and the width parameter to match.
-Johan
For rapid layout testing etc. there’s nothing wrong with a visual method. Just because the existing editor is outdated (does not support all controls, nevermind .NET ones) or produces errors (and has for years) does not change that fundamental advantage.
You can always go back and let the mysterious MaxScript layout engine take care of things once you have your basic dialog designer and add tweaks later.
=====
by the by, your example errors out on first run… things inside the rollout don’t know what the rollout itself is if it doesn’t already exist;
undefined
-- Error occurred in anonymous codeblock; filename: ; position: 663; line: 21
-- Unknown property: "width" in undefined
you’d have to set width/height variables in the rollout before opening the dialog itself with those width/height values, I think
I have to say I’m with rich on this one, VMXS is far from perfect, but still very fast to layout basic UIs. But I like your methods listed here Johan. I will add that when i opened 2010 (my subscription copy finally arrived) there were none of the intial problems with extra characters being added :shrug:
Oooh, so now you both are teaming up huh…
I see my mistake and will correct it. It’s a scope issue offcourse. Also one of the things I don’t like about rollouts. I would like to inject code to the rollout before opening it, but it seems some things cannot be redeclared so easily.
I really never touch the VMS, it must be a personal thing then. With my abbreviations properly set, I can simply and quickly layout (even dotnet) controls in notime. Since I try to follow good naming conventions on my tools, I have all prefixes already setup in the abbreviations. So I type
btn
press CTRL+Shift+A and :
button btn "" width: height: offset:[0,0] align:#left across:1
Just type in what I need, swap buttons around is simply CTRL+T (transpose). I find it much faster then dragging and snapping and rearranging.
-Johan
p.s. Fixed the code a bit… not so dynamic anymore, but the workaround is not so pretty either…
LOL! yeah, I’m going to get my Dad as well
ideally* we’d just have full read/write access to width/height properties of controls in addition to the .pos property, and access any custom propertis. Then you can always write your own layout engine (say, based on percentages and alignment options). Can already do this for .NET-based forms/dialogs, but not all controls for max are available as .NET equivalents :\
- I suppose that ‘ideally’ an existing more powerful layout engine would be used. Wonder how long it’ll be before all the dialogs will be WPF-based