[Closed] Bobo's "fast tool development" video

2008? hmm… tool creation technique changed a lot since that time. at least my technique.

for example… look at the question in the thread… how to store a rollout values with max file? all suggestions from this thread are looking a little outdated today.

I’m really just looking for some solid guidelines / best practices for savvy tool scripting.
something beyond what the help files contain.

Things like how to go about using struct /roll-out pairs
(a wiki article now lost to the tech-art.org )

I suppose I’ll just keep doing it wrong and learn from my errors

100% matches my experience.

Dennis your struct summary above is pure gold, thank you.

One question:
if the “modern” roll-out definitions are now functions within a struct, how is the UI commonly launched?
is there also createdialog / newrollout floater code within the struct, allowing commands like

myStruct.displayRollout()

or is it better practice to keep the ui launching seperate

struct mystruct(...)

global thefloater=newRolloutFloater  "" 200 100
addRollout mystruct.myrollout theFloater

here is it:

 global GeneralSceneOps 
 (
 	struct GeneralSceneStruct
 	(
 		fn destroy = try(closeRolloutFloater GeneralSceneOps.dialog) catch(),
 		
 		title = "General Scene Helpers",
 		dialogWidth = 250,
 		dialogHeight = 400,
 		dialog,
 		
 		MatStruct =
 		(
 			struct MatStruct (material, slot)
 		),
 		ObjectRollout = rollout ObjectRollout "Objects"
 		(
 			local owner = if owner != undefined do owner
 			button deleteall_bt "Delete All Objects" align:#left width:(owner.dialogWidth - 30) offset:[-5,0] 
 			on deleteall_bt pressed do undo "Delete All" on
 			(
 				format ">>> %
" owner
 				delete objects
 			)
 		),
 		materials = #(),
 		MaterialRollout = rollout MaterialRollout "Materials"
 		(
 			local owner = if owner != undefined do owner
 			button collectmats_bt "Collect Editor Materials" align:#left width:(owner.dialogWidth - 30) offset:[-5,0]
 			on collectmats_bt pressed do 
 			(
 				owner.materials = for k=1 to 24 collect (owner.MatStruct (medit.GetTopMtlSlot k) k)
 				format "mats: %
" owner.materials
 			)
 		),
 		rollouts = #(ObjectRollout, MaterialRollout),
 		fn show = 
 		(
 			destroy()
 			dialog = newRolloutFloater title dialogWidth dialogHeight
			for r in rollouts do addRollout r dialog
		),
 		on create do
 		(
 			destroy()
 			rollouts.owner = this
 		)
 	)
 	GeneralSceneOps = GeneralSceneStruct()
 	ok
 )
 GeneralSceneOps.show()
 

this snippet mostly shows my style of tool design. don’t try to find a sense in the button functions

Nice summary, Denis !

What exactly is point of encapsuling the whole thing in a global scope ?
Isn’t that enough ?

global GeneralSceneOps;
 
struct GeneralSceneStruct
 (
 	...
	same things as you
	...
 )

 GeneralSceneOps = GeneralSceneStruct()
 GeneralSceneOps.show()

Is there any differences between the both ways?

thank you a million times, Dennis.

The fact that the use of a mxs struct has evolved makes for outdated search results for those of us just starting.

It leads me to wonder about another aspect of max tool development which may have evolved : distribution and installation of tools to the team. I think I’ll start a fresh thread about that…

quick question
what’s the purpose behind the OK statement that follows the struct instancing?

got it

max help didn’t clearly indicate that effect.

what about

[...]

                 local owner = if owner != undefined do owner

[...]
 		on create do
 		(
 			destroy()
 			rollouts.owner = this
 		)

the latter part seems to set a .owner property to the struct
but what’s the first part do? seems odd to “do” a property…