Speed of code in ArcGis Extension

[ThibautDusanter]

Hi,

I have a serious issue regarding the speed of the code I am writing in my ArcGIS extension:

I have written a process in order to read some data from an access database.

- The ArcGis extension is controlling a TCP/IP server such that the database path can be received from an XML sent over the network.
- There is also a command button that allows doing the same thing by specifying manually the database path (it is also calling the IExtension function on the onclick event).

both ways work correctly with the TCP/IP server turned on. However the click on the button is much much more faster (1s againt 7min) that the network  stuff. The problem is not coming from the network communication because the database path is received very quickly (I checked by debugging).

Does someone have an idea? I am quite desesperate because I don't have any clue how to solve it!!!

Thanks a lot

[RichardWatson]

Hi,
- The ArcGis extension is controlling a TCP/IP server such that the database path can be received from an XML sent over the network.

I suspect that the problem lies here.  What does the code specially do?  I am wondering how you are notified that "the XML was sent over the network".  Did you create a different thread?

[ThibautDusanter]

Thank you for your response.

So there is another Command button that is starting a TcpListener. The TcpListener is associated with a new thread to listen to new clients. And each client is associated to one thread in order to listen to new data.

The thing is that this server is always turned on while testing (both for the command through xml or command through button click option). So to my mind it can´t be responsible for the slowing down.

What do you think?

Thanks a lot,

[ThibautDusanter]

After reading your message, i may have found the solution

Calling ArcObjects from a thread other than the main thread
In many multithreading applications, you will need to make calls to ArcObjects from different running threads. For example, you might have a background thread that gets a response from a Web service, which, in turn, should add a new item to the map display, change the map extent, or run a geoprocessing (GP) tool to perform some type of analysis.
A very common case is calling ArcObjects from a timer event handler method. A timer's elapsed event is raised on a ThreadPool task (a thread that is not the main thread). Yet it needs to use ArcObjects, which seems like it would require cross-apartment calls. However, this can be avoided by treating the ArcObjects component as if it were a UI control and using Invoke to delegate the call to the main thread where the ArcObjects component is created. Thus, no cross-apartment calls are made.
The ISynchronizeInvoke interface includes the Invoke, BeginInvoke, and EndInvoke methods. Implementing these methods can be a daunting task. Instead, have your class directly inherit from System.Windows.Forms.Control or have a helper class that inherits Control. Either option provides a simple and efficient solution for invoking methods.
The following code example uses a user-defined InvokeHelper class to invoke a timer�??s elapsed event handler to re-center the map's visible bounds and set the map's rotation.

I am going to investigate this.

Is it what you were refering to rlwatson?

Thanks again

[RichardWatson]

ArcMaps use a model which ESRI refers to as threads in isolation which is a fancy way of saying that all access to them is marshalled back to the creation thread, i.e. they are not multi-threaded.  The way that all of this works is that Single Threaded Apartments (STA) are used by ArcObjects and they get messages across apartments/threads when the Windows message pump runs.  If the messages are not pumping then nothing will be heard.

What I wanted to understand is how exactly you structured your code because of the above discussion.

You should be able to set breakpoints and/or log messages which will tell you where the delay is.  My guess is that it is related to the above.

[ThibautDusanter]

Hey rlwatson,

I found the solution using the example "Calling ArcObjects from a thread other than the main thread" in the page:
http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//000100000100000000

I used an InvokeHelper class as mentioned.

Regarding the debugging with breakpoints/log message (as you suggested), I tried it before and it was not working. The problem really lies in the fact that I was calling the function from another thread (the thread of network listening).

Thank you for your help