.net WorkerThread The calling thread cannot access this object because a different thread owns it

[Cliff B]

I've got some code that runs a long process and I've wrapped it in a worker thread and display a looping progress bar to give the user some indication something is happening.
This works fine with calling a Do on the old DMapBasicApplication Interface
However when doing the same thing calling RunMapBasicCommand in the IMapInfoPro interface get the error The calling thread cannot access this object because a different thread owns it.

Has anyone experienced this, does anyone know a workaround?

[Thomas Bacon]

Hi Cliff,

 

Have you got a sample of the code that throws the error? Usually in .NET you would use the Invoke method to execute some code using the thread that owns a control’s specific window handle. I’ve often used this in the past to update a GUI (e.g. a progress or status bar) on the main application thread from a worker thread that is executing some long running process.

 

https://msdn.microsoft.com/en-us/library/system.windows.forms.control.invoke(v=vs.110).aspx

Tom

--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

______________________________________________________________________

Mouchel Limited I Registered in England No. 1686040 Registered Office: WSP House, 70 Chancery Lane, London, Wc2A 1AF Part of WSP Global Inc. Confidential This message, including any document or file attached, is intended only for the addressee and may contain privileged and/or confidential information. Any other person is strictly prohibited from reading, using, disclosing or copying this message. If you have received this message in error, please notify the sender and delete the message. Thank you.
______________________________________________________________________

[Cliff B]

I'm not updating the UI in the thread just sending mapbasic commands to MapInfo to process.
Here is a sample app that shows the issue

https://drive.google.com/open?id=0B1RWo41F6VdCV2c3V18ycDVmOXc

[Thomas Bacon]

Hi Cliff,

 

Because you’re using a background worker thread and the form’s window handle is held by the main UI thread you’ll need to use the form to invoke the action within your delegate. This should work I believe:

 

                delegate (object Sender, DoWorkEventArgs WorkEventArgs)

                {

                    if(InvokeRequired)

                        this.Invoke(new Action(() => OpenTable()));

                    else

                        OpenTable();

                };

 

Best regards,

[Cliff B]

Hi Tom

That would get the  command to execute however it would run it in the UI thread locking it until the operation is complete. For an open table that's not an issue but something more complicated like a big update, or select where intersect statement would mean the app goes unresponsive while the query runs.

I think I've found the problem though, it appears the IMapInfoPro.RunMapBasicCommand method seems to ignore the echo parameter and always prints the statement in the mapbasic window.

I think a workaround might be to have to use IMapInfoApplication instead of IMapInfoPro, is there a way I can get a pointer to that from MapBasic?

[Cliff B]

I've come up with a workaround which whilst isn't pretty does work.
I pass the instance of the IMapInfoPro and the DispatchID for the .Net method, I can then use the IMapInfoPro for creating the unattached window now needed to embed a map. Whilst still using the DMapInfo to process map basic statements.
This works for now, however unlike in x32 MIPro all errors are raised in MapInfo so when running a .Do statement there is no way to trap the error.