Perfect, thanks. so far I think that I have a working model of what I’m after.

I gather it is just doing things with the Max viewports that causes issues is that right?

I’ll stir the pot a little more:

1. I’ve gotten the background worker to update meshes in the viewport, it’s documented in this thread. You can even click a link and watch a youtube video of the background worker merging in max files in the background. (!) It’s not 100% stable.
2. On my laptop, the background worker crashes rarely. On my i5 home desktop, the background worker crashes all the time. On my work computer (12 core intel mac), the background worker crashes all the time. I’ve checked with other maxers on different boxes, they get different results.
3. So, I’m going to go out on a limb and say that the hardware has something to do with it. I don’t know if it’s 32bit, 64bit, intel chips, amd chips, os versions, max versions, or what. There is a lot to consider. But I’ve watched my example scripts (posted to this thread) perform differently on different systems with different versions of max installed.

When I first tested it, it worked perfectly for me but that was in another version of Max on the same machine so I’m not sure that it is just the hardware.

OK, I’m back again working on a test for this.

I have many labels and I’m painting into each when the time changes so I want to thread that so that it isn’t slowing the Max viewport. I can see how to build and create a UI in a thread as the whole thing gets done in the thread but I want to paint into existing UI items.

First off is this the way to go about it?

I’m not seeing a way to have the paint function in the thread. I just tried building the forum in the backgroundWorker function and it crashed Max.

This works but not really what I think it should be. I also don’t have any updating happening here with a callBack for updating the painting so nothing really happens. But is this even going in the right direction?

col=(dotNetClass "system.drawing.color").red
brush=dotNetObject "System.Drawing.SolidBrush" col
form=dotNetObject "form"

fn backGroundFn sender arg=
(
	fn formPaint sender arg=
	(
		g=arg.graphics
		for i = 1 to 100 do
		(
			g.FillRectangle brush (dotNetObject "system.drawing.rectangle" (random 0 300) (random 0 300) 10 10)
		)
	)
	dotNet.addEventHandler form "paint" formPaint
)
sysPointer=dotNetObject "system.intPtr" (windows.getMaxHWND())
maxHandle=dotNetObject "maxCustomControls.win32HandleWrapper" sysPointer
form.show maxHandle
	
MainThread = dotnetobject "CSharpUtilities.SynchronizingBackgroundWorker"
MainThread.WorkerSupportsCancellation = true		
dotNet.addEventHandler MainThread "DoWork" backGroundFn

if MainThread.isBusy == false then 
(
	MainThread.RunWorkerAsync()
)

that’s how it might be:

    try(form.close()) catch()
try(worker.dispose()) catch()

form = dotNetObject "form"
brush = dotNetObject "System.Drawing.SolidBrush" (dotNetClass "system.drawing.color").red

sysPointer = dotNetObject "system.intPtr" (windows.getMaxHWND())
maxHandle = dotNetObject "maxCustomControls.win32HandleWrapper" sysPointer
form.show maxHandle
	
fn backGroundFn sender arg =
(
	arg.Argument[1].Invalidate()
	g = arg.Argument[1].CreateGraphics()
	seed currenttime
	for i = 1 to 100 do
	(
		g.FillRectangle arg.Argument[2] (dotNetObject "system.drawing.rectangle" (random 0 300) (random 0 300) 10 10)
	)
)
	
worker = dotnetobject "System.ComponentModel.BackGroundWorker"
worker.WorkerSupportsCancellation = true		
dotNet.addEventHandler worker "DoWork" backGroundFn

unRegisterTimeCallback onTimeChanged
fn onTimeChanged = 
(
	if not worker.isBusy do 
	(
		worker.RunWorkerAsync #(form,brush) 
	)
)
registerTimeCallback onTimeChanged
    

the painting is doing in another thread.
but control’s redraw is in main of course.

I see, didn’t think about passing more arguments, well done.

This is going to cause me a whole pile of rewritting in the tool but should make it faster. I will see what I can get as a spew boost from it.

I agree with Denis.
I was afraid that such statement w’d sound too heretical,
so I’m a bit happy that he take an initiative about.
Hacking an engine build with no MT in mind via .Net or whatsoever…
somehow too easy to be true

I keep an eye on it.

A couple other ideas for the backgroundWorker are in the area of data collection. Recurring all the controllers or recurring folders lookin for files to possibly display them in a tree view. Dotnet UI’s can also take time to build some times so even adding that to a thread might be a good idea.

As soon as I can get back to this I will be testing controller recursion and maybe even speeding up the UI building with it.

Where have you read that?

http://msdn.microsoft.com/en-us/library/ms171728.aspx

It is unsafe to call a control from a thread other than the one that created the control without using the Invoke method.

I assumed this also meant painting, but I have not actually tried it myself.