Permalink Reply by Dale Fugier on March 20, 2013 at 10:25am Sorry, no. Why do you need to do this?
-- Dale
Permalink Reply by Varun Bhartiya on March 20, 2013 at 10:03pm
Permalink Reply by Dale Fugier on March 21, 2013 at 9:56am Hi Varun,
Why not have the command start the background process and not let the command end until the background process is complete?
-- Dale
Permalink Reply by Varun Bhartiya on March 22, 2013 at 3:11am
Permalink Reply by Dale Fugier on March 22, 2013 at 10:51am I guess I need more about what you are doing. What kind of calculaton are you making? What do you want to see in the UI - the existing model or new geometry? Hopefully you won't be accessing the Rhino document from your calculation thread, as Rhino is not thread safe.
More details would be appreciated.
Thanks,
-- Dale
Permalink Reply by Varun Bhartiya on March 25, 2013 at 7:03am Hello Dale,
Before it starts a background thread, it creates a copy of the currently open document.. Then in the background it is uploading this document to the server. So we want to restrict user from editing this document till the upload is complete. (He should still be able to visualize it, pan, zoom, etc)
Another use case is to download a document from the server in background and when the download is complete, open this downloaded document.
Regards
Varun
Permalink Reply by Dale Fugier on March 25, 2013 at 3:34pm Hi Varun,
Like I mentioned, from within a command start your background process. But, do not let the command finish until the background process is complete. While your background thread is running, have the main thread poll to see if it still running, and if so call Rhino.RhinoApp.Wait. This will keep the Windows message pump alive so views will update and windows will repaint.
Sorry I don't have sample that demonstrates this, but it should take much if you understand threading.
-- Dale
© 2013 Created by McNeel Admin.
