[Closed] Staying within a function

There are other ways, but the easiest is to make your dialog modal. This will halt any maxscript execution until the dialog has been closed.

The only way to actually pause code execution with a prompt is by using a messageBox, queryBox or yesNoCancelBox. For example, an if queryBox() do () expression actually halts in middle of the test expression and waits for the required boolean result from the user’s input.

On the other hand, code that creates a modal dialog keeps running until completion, but the modal dialog simply locks out any additional user input that could trigger more maxscript execution or scene changes. This is a very important distinction for scripting.

There is no way to stay within the function as you described it. It is the rollout definition that will remain, with all of its event handlers ready to do what you’ve told them to do. The Store_Multi_Geometry function will be completed and its local scope gone once the last command inside of it completes, which happens to be the createDialog command.

You have to shift your thinking here and look at it from the dialog’s point-of-view. Once the Store_Multi_Geometry() function completes its last command, it is no longer in control…the dialog is. Change your function’s name to CreateStoreMultiGeometryDialog() and you’ll start to see it. The rest of your code has reached completion…the modal property of the dialog is simply locking down the max UI until the user or your dialog’s code closes the dialog.

At this point, all of the remaining work can now only be done from inside the rollout definition’s event handlers. These event handlers can see their own local scope, the outer local scope of the rollout definition itself, and the global scope…but nothing else. The local scope of the Store_Multi_Geometry() function was not only invisible to them, it is also now gone…that function completed and that scope closed as soon as the dialog was created.

By the way, if createDialog() had not been the last command in your function (e.g. if you had some other cleanup at the end of the function), those commands would have executed immediately after the dialog was created. That function is not waiting for the newly created dialog to do anything…it would have created the dialog, left it where it was and kept going through its remaining commands.

Here’s how I usually do this. The Store_Multi_Geometry_Result variable below is created in the initial scope, which makes it visible to all nested scopes. So it can be accessed from within an event of the rollout, as well as after the Store_Multi_Geometry() function call. Key here is to use modal:true to make sure any code after the Store_Multi_Geometry() call is halted until the dialog is closed.

(

-- create a local variable to store the dialog's result
local Store_Multi_Geometry_Result


fn Store_Multi_Geometry =
(
	rollout MultiObjectRollout "" width:183 height:252
	(
		MultiListBox Object_List "Choose Object (s) to store" items:#("Object 1", "Object 2", "Object 3", "Object 4", "Object 5") pos:[18,35] width:144 height:10
		groupBox ObjFile "" pos:[9,15] width:165 height:193
		button OKbtn "ok" pos:[30,218] width:61 height:21
		button CancelBtn "cancel" pos:[94,218] width:61 height:21

		on CancelBtn pressed do destroyDialog MultiObjectRollout

		on OKbtn pressed do
		(
			-- store selected items in the dialog result variable
			Store_Multi_Geometry_Result = for i in Object_List.selection collect Object_List.items[i]
			
			destroyDialog MultiObjectRollout
		)
		
		on MultiObjectRollout open do
		(
			-- initialize the dialog result variable when the dialog opens
			Store_Multi_Geometry_Result = #()
		)
	)

	createDialog MultiObjectRollout style:#(#style_sysmenu, #style_resizing) modal:true
)


Store_Multi_Geometry()

format "You've selected : %
" Store_Multi_Geometry_Result


)

Cheers,
Martijn

Thank you both for your descriptive reply’s. It is very much appreciated. .

Martijn, the code works great, thanks