Putting together an RTD server is not particularly difficult… once you know how to do it. Hopefully this guide will shorten your learning experience
In How RTD servers work we saw what happens when a user types and RTD formula in a cell. Here I shall try and map that to the dataflow it generates amongst the class instances in GeodesiX.
The blue items are instances of an object, the black labels are method calls. If this is your first reading, print the digram, it’ll be easier to follow:
From now on, when I refer to a tuple “A.B.C”, I am directing you to project/namespace A, class(module) B, Method C.
The bullet numbers correspond to the 18 #N# codes in the source code.
- The user enters the formula =RTD(“GeodesiX.RTD”,,”geocode”, “status”, “Tokyo”) in cell A1.
Excel searches for a registered RTD server called GeodesiX.RTD.
It calls the Connect method with the topics “geocode”, “status” and “Tokyo”.
- The addin interface marshals the call to managed code and calls GeodesiX.RTD.Topic_Connect.
- Topic_Connect determines that this a Geocode call and dispatches it to Gedesic.Cache.InitiateGeocode.
If InitiateGeocode finds the query “Tokyo” in the cache it returns and we’re done (Excel will call RefreshData later to get the value).
If not, it creates a geocode query and passes it to Geodesics.Geodesic.Find
- Find adds the query to an internal queue, starts the worker task if necessary, and returns (to Excel).
Note that these first 4 steps are quick, so that the user interface remains snappy.
- Asynchronously, the worker task takes the next query off the queue.
It raises the Started event to notify listeners that it beginning a query.
It continues doing this as long as there are entries in the queue.
- The worker passes each query to Geodesics.Geodesic.Resolve.
- Resolve determines the query type (Geocode or Travel/Directions).
It sends a REST HTTP request to Google and receives a JSON answer in return.
It calls GetLocations to parse the JSON object into a list of Locations.
The worker raises the Completed event to notify listeners that it has finished a query.
- Resolve calls GeodesiX.Cache.GeodesicComplete on the worker thread.
- GeodesicComplete uses the previously saved Excel SynchronizationContext to queue a call to GeodesicCompleted (notice the “d” at the end).
- On Excel’s UI thread
GeodesicCompleted sees that the query is a Geocode and passes the query to GeodesicCompletedGeocode, who updates the cache.
- GeodesicCompleted calls Excel’s UpdateTopics on Excel’s UI thread, to provoke Excel into issuing a RefreshData
- Some time later, when it has nothing else to do, Excel calls RefreshData.
- The addin interface marshals the call to GeodesiX.RTD.RefreshData.
- RefreshData Calls GeodesiX.Cache.Geocode to obtain the query and passes the result back. RefreshData returns the A1 cell value to Excel.
- Separately, sometime later, the user enters =Geocode(“status”, “Tokyo”) in cell B1. Excel calls the Geocode UDF.
- The interface marshals the call to managed code and calls the UDF GeodesiX.UDF.Geocode, who looks to see if “Tokyo” is in the cache.
If it is, it simply returns the “status” result; this is the end of all things to do with RTD and the vallue of B1 is fixed forever.
- If “Tokyo” isn’t in the cache, Geocode returns =RTD(“GeodesiX.RTD”,,”geocode”, “status”, “Tokyo”), which tells Excel that this cell needs to be updated by RTD, and we return to step 1.
The moral of the story is that in the end, =Geocode() formulas will eventually return the relevant value #17# (once the RTD has got it) and there will be no more RTD updates on the spreadsheet.
This is not how a typical RTD server works; the UDF wrapper would normally always return the =RTD() #18# function so that updates are continuously received.
Note: Because of this, the Disconnect interface is never used.
Sorry if that was a bit windy, the rest is relatively plain sailing.