Duplicate inbuilt 'identify' function for add-in

[BabbageOcelot]

Hello dev guys & gals,

I know it's an odd request, but bear with me. My users are so used to having to click a button, to then identify, I'd like to give them one via an add-in; just clicking on the map is a bit of a leap! Something which changes the cursor to a crosshair would make them feel a lot better. I can also give them feedback if there's nothing there, as opposed to just doing nothing.

Is there a code shortcut to duplicate the click functionality - that is: detect click in MapDisplay, identify, bring up list of elements at point - of the inbuilt map click? Appending to MapDisplay.MapItemClicked doesn't do anything, and MapDisplay.GraphicClicked appends to the function click only on graphic overlays, which isn't really what I want.

I'd also like to add the identify location into a folder in the content pane, rather than have it stick around until the map is moved and then disappear, so it's not going to be a straight reference to the click handler...

Lastly: noted in the (hilariously techno) Explorer 1500 preview video what looks to be identify-by-area. Which is another thing users here really want, and is a job less for me. Is this the case? Hope so! 🙂

Is there a proposed feature list somewhere?

Thanks.

[MichaelBranscomb]

Ben,

When debugging the code are there any errors / messages?

Regards

Mike

[BabbageOcelot]

Ben,

When debugging the code are there any errors / messages?

Regards

Mike

Mike,

ah... I was hoping this would be a "Oh, we know about this..." sort of thing.
I'm afraid all that comes back is a SOAP fault:

<soap:Fault>
         <faultcode>soap:client</faultcode>
         <faultstring>Error processing server request</faultstring>
         <detail/>
      </soap:Fault>

After some analysis, the SOAP requests sent for the two services (same mxd file, different publishing method) are wildly different. I'll attach them, but in short the <LayerDescription> element in the msd request is quite minimal:

<ScaleSymbols> is set to false.
There is no empty <SelectionFeatures/> element as there is in the mxd request.
There is no <SelectionSymbol> element.
There is no <SelectionBufferSymbol> element.

I'll have a look at forcing these elements; at the moment this is all I have to go on. Hope it makes sense.

Thanks,

Ben.

[MichaelBranscomb]

Ben,

I believe you're receiving Tech Support on this issue currently? - if that's the case probably better to pursue through that avenue for better traceability.

I'm not currently aware of any differences in the WSDL between an MXD-based service and an MSD-based service. However, it's possible that my Add-in was using an old SOAP proxy library. Perhaps try downloading the 10.0 pre-generated proxies (or generate new ones yourself if you prefer) - http://help.arcgis.com/EN/arcgisserver/10.0/apis/soap/Pre-generated_proxies.htm.

Regards

Mike

[BabbageOcelot]

Hello Mike,

Yes - there's a tech support request out for this... the link you sent to the library was very helpful.

It turns out that msd-published services behave differently to mxd-published ones with regard to the ImageDisplay attribute of the SOAP request. Mxd-published services don't care if the ImageDisplay is created with the default constructor & sent on its way; to make it work with msd-published services, you have to set the width, height and dpi.

// Fails with msd-published services
ImageDisplay imageDisplay = new ImageDisplay();

// Works for all services
ImageDisplay imageDisplay = new ImageDisplay();
imageDisplay.ImageHeight = 500;
imageDisplay.ImageWidth = 500;
imageDisplay.ImageDPI = 96;

Thanks for your time on this, at least by using the compiled .dll I could remove that from the possible causes. The SOAP API C# Examples were also pretty handy for creating test cases.

Hope this is of help to someone out there!