[Closed] pausing maxscript execution without UI lock

yes, there is. you can run mxs code in a different thread. but… if this code does do nothing with max scene and max built-in ui… it might look like a code works for these two cases too, but it’s not safe. sooner or later the code will crash.

hi dennis,

I tried a .net backgroundworker in the meantime which is executing

ManagedServices.MaxscriptSDK.ExecuteMaxscriptCommand(“Box()”);

Thread.Sleep(10000);

in the work event.

but, as you already mentioned, it crashes during the 10 second sleep time…

unfortunately I want to manipulate the scene in my code

Lately I’ve been toying with the idea of invoking scene-manipulating code from a background thread using max’s own timer ui element.

The trick is that the timer is internally implemented using Windows messages to the max window, and thus always executes on the UI thread.

See the following code, can you make it crash?

(
	fn CurrentThreadID =
	(
		(dotnetClass "System.Threading.Thread").CurrentThread.ManagedThreadID
	)

	fn sceneManipulatingAction =
	(	
		format "Invoking action on thread: %
" (CurrentThreadID())
		box pos:(mapScreenToCP mouse.pos)
	)

	rollout threadSyncRol "Thread Sync"
	(
		local action	
		local sync
		
		timer tim active:off interval:1
			
		on tim tick do
		(
			tim.active = off
			action()
			sync.Set()
		)
		
		fn invokeAction actionFn syncEvent =
		(		
			action = actionFn
			sync = syncEvent
			tim.active = on
		)
	)

	createDialog threadSyncRol pos:[-2000,-2000]

	fn bgThread s e =
	(
		format "Starting BG work on thread: %
" (CurrentThreadID())
		local syncEvent = dotNetObject "System.Threading.AutoResetEvent" false
		for i = 1 to 50 do
		(
			::threadSyncRol.invokeAction sceneManipulatingAction syncEvent
			syncEvent.WaitOne()
			sleep 0.1
		)
		::threadSyncRol.invokeAction (fn f = destroyDialog threadSyncRol) syncEvent
		syncEvent.WaitOne()
		syncEvent.Close()
		
	)
	
	format "UI thread ID: %
" (CurrentThreadID())
	bgw = dotNetObject "System.ComponentModel.BackgroundWorker"
	dotnet.addEventHandler bgw "DoWork" bgThread

	bgw.runWorkerAsync()
)

This method won’t help you create 10000 boxes faster than you could create them in one thread, but it does seem to enable you to keep the UI unlocked while executing scene-altering code in a background thread.

Inside sceneManipulatingAction obviously

i’m probably missing something. it definitely locks UI at the time of any scene modification.
it’s easy to see by changing the action:

	fn sceneManipulatingAction =
	(	
		format "Invoking action on thread: %
" (CurrentThreadID())
		arr = for k=1 to 1000000 collect (random -1e9 1e9)
		sort arr
		free arr
		--box pos:(mapScreenToCP mouse.pos)
	)

for example

Hi lo,

I tried the code (I guess the ‘::’ was not intendet) and it’s definitvely an interesting solution. Unfortunately it’s not working for me that i can see…

I oversimplified my mxs code to:

f1()

waitWithoutUILock()

f2()

which is not correct since it’s more:

f1=(
print “do something”
waitWithoutUILock()
f2 “1” “2”
)

f2 p1 p2=
(
print “do something”
waitWithoutUILock()
f3 param
)

My need is to pause during the execution of f1 before f2 is called to wait for user input and let the user explorer the scene after f1 was nearly completed. Then whenever the user decides to continue, f2 is executed.

Your solution is a good option if my call of f2 is not inside the f1 but for me that’s necessary. And sometimes I have to stop multiple times in the f1 so not only f2 is called, there might be f3 f4 and so on.

but thanks anyway!

Hi

you could use this structure:

rollout threadSyncRol "Thread Sync"
(
	local action, sync
	timer tim active:off interval:1
		
	on tim tick do
	(
		tim.active = off
		action()
		sync.Set()
	)
	
	fn invokeAction actionFn =
	(		
		sync = dotNetObject "System.Threading.AutoResetEvent" false
		action = actionFn
		tim.active = on
		sync.WaitOne()
		sync.Close()
	)
)
createDialog threadSyncRol pos:[-2000,-2000]

fn WaitForUserApproval =
(
	global approveRol
    rollout approveRol "Press Ok to Continue"
    (
        local syncEvent
        button btnOk "Ok"

        on btnOk pressed do
        (
            syncEvent.set()
            destroyDialog approveRol
        )
    )  
    threadSyncRol.invokeAction (fn f = createDialog approveRol)
	local sync = dotNetObject "System.Threading.AutoResetEvent" false
	approveRol.syncEvent = sync
	sync.WaitOne()    
)

fn f2 =
(
	fn f2OnUiThread =
	(
		print "f2"
		--all your scene related work		
	)
	threadSyncRol.InvokeAction f2OnUiThread
	WaitForUserApproval()
	print "finished f2"
)

fn f1 s e =
(	
	fn f1OnUiThread =
	(
		print "f1"
		--all your scene related work		
	)
	threadSyncRol.InvokeAction f1OnUiThread
	WaitForUserApproval()
	f2()
	--clean up
	threadSyncRol.invokeAction (fn f = destroyDialog threadSyncRol)	
)

bgw = dotNetObject "System.ComponentModel.BackgroundWorker"
dotnet.addEventHandler bgw "DoWork" f1
bgw.RunWorkerAsync()

When I think about it, you don’t need threads at all.
You can just do this:

fn WaitForApprovalAndThen action =
(
	rollout approveRol "Press Ok to Continue"
    (
        local action
        button btnOk "Ok"

        on btnOk pressed do
        (
	    destroyDialog approveRol
            action()            
        )
    )  
    createDialog approveRol
	approveRol.action = action
)
	

fn f2 =
(
	print "f2"
)

fn f1 =
(
	print "f1"
	WaitForApprovalAndThen f2
)

f1()

again to much simplification from my side… my f1 contains a loop…

fn process =
(
–manipulate scene
a = box()

    for k in children do
    (                
    	k.process()
        WaitForApprovalAndThen f2 k
     )

    -- undo scene manipulation
    delete box()

)

maybe a bit more explanation from my side would be useful:

I have a existing node based scene manipulation system where every node manipulates the scene. after the current scene manipulation system (like creating a box the children are processed. after the children processing the operation should be undone – e.g deleting the box. now to check if each function does what it was supposed to I want to pause the code and then continue. a modal dialog is nearly perfect since it’s pausing the code but the user can’t rotate the viewport and so on, but at the end I’m probably going to live with that for the moment…

even if i would store a function list as arrays as a callstack in the rollout and execute them one after another all my call parameters would have to be stored in the rollout too which is hard to implement for a complex existing code.

but i’m sure your technique might be very useful for other cases!