Hi there, guys,
I seem to need to write more and more complex GUIs when it comes to pipeline integrations etc… and I was thinking of having a support of multiple threads in a GUI context.
What I mean is I want the GUI to draw fast and wait for data to be pulled from elsewhere (such as Shotgun, Tactic etc…), but, transparently to the user. When the data is finally available, I want to update certain GUI elements.
For example, I’m currently writing a custom render farm submitter and I want to source a lot of stuff from Shotgun. But, it takes a second or two to get the response from the Shotgun servers. I don’t want the GUI to become unusable/grayed out or anything, I want the user to just keep filling up their fields and only when the data is finally ready from Shotgun, it gets filled in.
A visual cue (i.e. an hour glass animation or anything) in the control objects that are waiting for the data would be a super sweet bonus, but not necessarily a must.
I’m talking, obviously, about writing all this using .NET objects/classes from ground up, so, I am certain this can be done, however, I have very little idea where to begin. I’m not much used to writing multithreaded scripts.
Thanks a lot for any tips and hints in advance!
to summarize thing in an overly simplistic way:
at the beginning of your UI refresh (I guess when it opens?):
- Set your controls to their ‘waiting…’ state … this really depends on the type of control.
- Start a BackgroundWorker whose job will be to get the information from Shotgun in a seperate thread.
– when the backgroundWorker finishes its job:
- from it’s RunWorkerCompleted you must Invoke the UI controls you wish to update. I don’t quite remember how to invoke standard dotnet controls in maxscript without using a custom assembly for the delegates, I’m not sure it’s possibe. But maybe someone else knows…
Pete Addington (LoneRobot) has a nice article on using BackgroundWorkers in maxscript:
http://lonerobot.net/?p=50
Thanks for the tips.
I know about the backgroundWorker (from Pete, of course ), just wasn’t sure about the rest of the process as you described.
I’ll give this a shot and see what happens.
Thanks
another option is to have the main thread query the state of the data retrieval periodically (like every 100ms or so) using a timer, instead of invoking it from the BGWorker thread. Not as ‘correct’, but in the context of maxscript it might be easier and simpler to implement.
That actually sounds like an easier path. I might try both, but will start with this one.
Thank you.
Hey Loocas, Rotem,
the only thing really to handle is the updating of components from the work thread. I sure rotem meant to say the progresschanged event, as runworkercompleted is for when it’s done.
As you’re doing this with dotnet rather than maxscript Loocas, i would try to write a user control with as much of the functionality in dotnet, and just host it on a rollout in max. (hitchhiker’s bitmap resizing code is threaded and free from the UI so it runs in the same way)
Another option is to use a control like the datagrid, which can be databound on a separate thread or limiting the data that you retrieve to what can be seen on the ui initially, and thread the retrieval of the rest of it. I guess this would depend on how you retrieve the data from shotgun in the first place.
You’re right, I was not taking into account there would be multiple controls to update. Progresschanged is the way to go.