Why the hate for Rollout Creator? I know it’s not the best, but in my company’s tools we use it fairly often (granted our “dynamic” needs are very simple) and it’s been really useful.
For example, I build a menu listing all the .max files found through a recursive search of a given root folder.
To make it more readable for the artists, I separate the .max files into categories based on their folder names (we name them such that their first word tells us what kind of asset they are).
I could dump these into different groups and then add them to one rollout and then create the dialog or floater… but an even cooler solution was to go through a loop creating rollouts with Rollout Creator, and then add them all to one floater.
Having the files listed in their own rollouts by category means you can unroll the ones you don’t need to be looking at.
Here’s what I mean, with some pseudo-code:
local categories = *array of folder names*
--holds the names of the folders I found in my search, don't need to know it's size other than it's at least 1
local rollouts = #()
--the array of all the rollouts I end up making
for category in categories do
(
local maxFiles = *function that returns max files found in this category folder*
local rc = rolloutCreator (category + "Rollout") category
--creates a rollout for this folder's files, with its name being the folder name
rc.begin()
for file in maxFiles do
(
*add button and handler for this file to this category rollout*
)
rc.end()
append rollouts rc --add this rc to the array of rollouts I made
)
local newFloater = newRolloutFloater "File List*...
for roll in rollouts do
(
addRollout roll.def newFloater
)
See, so simple! I think sometimes if you’re doing something bare bones, RolloutCreator gets you 99, if not 100% of the way there.
I attached a screenshot to demo what I mean. This just searched a root folder, found 4 folders, with various max files found in them.
The Rollout Creator is a script with tons of bugs which is out of date and doesn’t do a job.
try to do the same with RolloutCreator:
fn makeCustomRollout name title dir:(getdir #maxroot) width:200 height:-1 =
(
local ss =
(
"
rollout {0} \"{1}\" width:{3} height:{4}
(
local dir = @\"{2}\"
button bt \"Print Directory\" width:({3} - 16) align:#left offset:[-8,0]
on bt pressed do
(
if doesfileexist dir do
(
format \">> %\
\" dir
for f in (getfiles (dir + @\"\\*.*\")) do format \"\ %\
\" (filenamefrompath f)
)
)
)
"
)
sb = dotnetobject "System.Text.StringBuilder"
sb.AppendFormat ss #(name, title, dir, width as string, height as string)
execute (sb.ToString())
)
dirFloater = newRolloutFloater "File List..." 208 200
dirs = #(#(getdir #ui, "User UI..."), #(getdir #temp, "User Temp..."), #(getdir #scripts, "User Scripts..."))
for k=1 to dirs.count do addRollout (makeCustomRollout ("dirRol" + k as string) dirs[k][2] dir:dirs[k][1] width:200) dirFloater
I don’t think that I have ever used rolloutCreator. Didn’t like it from day one. I think that I would look at your problem with subRollouts or if you want something even more dynamic then a dotNet UI embeded in a createDialog.
Are there any good guides/examples on dotNet UI and maxscript?
I’ve seen some general guides on dotNet, and plenty on maxscript UI’s, but not a lot on combining the two.
Probably isn’t too difficult to figure out, but I like learning best practices if they’ve already been figured out
it was some evolutionary migration process for me from max script UIs to .NET and WPF. some period i was using max dialogs with dotnet controls. today i don’t use the mixture of rollout and dotnet controls in the max dialogs. i always try to design my tools the way to use only max or .net solution, and try to avoid any combination.
Sorry to resurrect this thread but I think I finally found some ridiculous bugs in RolloutCreator which have been impeding me.
I think the main point is: RolloutCreator gets “confused” when you have too many controls/handlers and can’t keep them straight.
I build a dynamic UI based on info found in a XML file. I then write back to the XML file depending on what I do on this UI.
For that last step, I OFTEN find that RC messed up which handlers belongs to which control,and will often garble my XML file with the wrong information… or occasionally, not be able to find a control! I generate the names of the controls so that each one is unique and has a matching handler… sometimes I hit a button and Max tells me that the control is undefined.
Does this sound like typical RC buggy behavior?
I am going to experiment with Dennis’ method of building the dynamic rollouts with strings and then executing them.
Man, I wish I knew about this sooner, I’ve built several non-trivial UI’s with RolloutCreator, and assumed the XML bugs was due to some bad IO code on my end… turns out after switching to DotNot for XML I/O, the problems still existed and I’m 99% sure it’s the RC’s fault.
current Rollout creator is very buggy. i can easily fix these bugs because the script is very simple by my opinion, but… it’s outdated for sure. it needs to be completely rewritten.