PDA

View Full Version : Problem with Visual Maxscript in 2010


msmith81
05-04-2009, 06:23 PM
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!

thatoneguy
05-04-2009, 09:02 PM
Weird. Well report it as a bug. I doubt anyone tested the visual maxscript editor during the beta. :D

msmith81
05-04-2009, 11:55 PM
thanks for the quick reply. On the plus side, it doesn't seem to delete the last line after the rollout anymore. :shrug:

JHN
05-05-2009, 08:24 AM
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

JHN
05-05-2009, 08:36 AM
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

ZeBoxx2
05-05-2009, 08:55 AM
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

LoneRobot
05-05-2009, 09:49 AM
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:

JHN
05-05-2009, 10:17 AM
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.... :|

LoneRobot
05-05-2009, 10:39 AM
Oooh, so now you both are teaming up huh... ;)

LOL! :) yeah, I'm going to get my Dad as well :p

ZeBoxx2
05-05-2009, 11:11 AM
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 ;)

JHN
05-05-2009, 11:29 AM
Richard, I know what WPF means, but what is it. Is it the markup of a layout through XAML or something, like the 2010 ribbon? And how does WPF mingle with dotNet, is it an extension to it or a completely different thing altogether...? And why can't we use it yet...?

Pete, bringing your dad in is really no fair you know... it's realy not! Maybe some mxs guru here will adopt me and we'll have a fair fight.. ;)

Cheers,
-Johan

LoneRobot
05-05-2009, 12:49 PM
Maybe some mxs guru here will adopt me and we'll have a fair fight.. ;)


Damn! this could escalate quickly. You could end up with Paul Neale on your side, and I bet he fights dirty. What if I got my Dad to hold the towel? :D

ZeBoxx2
05-05-2009, 01:10 PM
I'd tell you if I knew for sure, Johan :)

near's I could figure out, the XAML describes the interface rather loosely.. i.e. what you want on it, and how it should be aligned relative to parent elements and such.

The layout engine of choice then actually turns that into a layout to be popped onto the screen.. essentially the width/height and x/y coordinates. There's multiple layout engines, can even write your own.
http://msdn.microsoft.com/en-us/library/ms752299.aspx#Add_Layout

Then there's the renderer, which actually displays the controls, along with visual styles, etc.

WPF is a part of .NET 3.0 - think of it as something like an alternative to the windows Forms.

As to why we can't use it 'yet'.. I haven't looked, but I guess you should be able to use it? You can certainly customize the 2010 ribbon; but you'll have to do so by hand until ADSK releases an editor for their flavor of XAML (existing editors seem to have issues with the 2010 XAML files)

LoneRobot
05-05-2009, 03:04 PM
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.

See that's why you don't use VMXS Johan, you actually use the new editor properly. :cool:

Kameleon
05-05-2009, 03:14 PM
Hey, you can check this research I did on WPF and that only I could run :D

http://forums.cgsociety.org/showthread.php?f=98&t=741179

ZeBoxx2
05-05-2009, 03:34 PM
<conspiracy mode>well, Kameleon, that's just a plot between Microsoft and certain interested parties to have everybody move over to 64bit platforms</conspiracy mode> ;)

back on-topic... it should be pretty simple to filter those out semi-automatically.. but the "semi-" part alone actually makes it about as much work as just removing those lines yourself / making a copy of the rollout for editing, edit, and then merge the changes into the original. The latter is a good idea anyway as one of the bugs I was referring to earlier is that the visual maxscript editor tends to mangle code layout, isn't able to deal with variables, etc.

JHN
05-05-2009, 03:50 PM
The latter is a good idea anyway as one of the bugs I was referring to earlier is that the visual maxscript editor tends to mangle code layout, isn't able to deal with variables, etc.

How eloquently put, I'd say it just sucks.... *runs

Another good thing about doing it yourself is the sense of pixels in for example a rollout for a scripted modifier, I can now fairly confidently estimate button width and offsets when building UI's for modifiers... yes indeed I can do that... hmm what's my point again...

:p

-Johan

msmith81
05-05-2009, 04:32 PM
Thanks everyone for the responses. JHN, those are some great tricks you shared! I will definitely start using some things like that. I am certainly not ready for all the crazy dotNet / WPF stuff you guys are talking about, those are things for me to learn in the future.

CGTalk Moderation
05-05-2009, 04:32 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.