topic Re: XBAP in IE in ArcGIS API for Silverlight Questions

XBAP in IE

davidrenz — Mon, 21 Mar 2011 22:03:38 GMT

has anyone had any luck using XBAP with IE?

we need to run a setup similar to an ActiveX control on a disconnected machine. I am wondering if anyone has been able to get this going.

thanks
david

Re: XBAP in IE

dotMorten_esri — Tue, 22 Mar 2011 16:07:29 GMT

This does work (although with a couple minor of limitations).
However, this is a client API and it needs a server to talk to, so disconnected scenarios are not something that is provided out of the box.
I'm curious... if you want to run in a browser anyway, why XBAP instead of Silverlight?

Re: XBAP in IE

davidrenz — Wed, 23 Mar 2011 22:07:29 GMT

Morten,

Thanks for the response.

We have a situation where we need to run our app from within another application.
That application has a browser window which we can run an activeX control (<object>) in.

I was kind of hoping to blend the Mobile Cache from the Mobile API and the WPF stuff to come up with a hybrid solution. We need to be able to support some intermittent disconnectedness, along with the problem of limited throughput (because it is going over 3G).

So, I was hoping to be able to serve up the XBAP from the file system (which i am gathering is not very possible) and use the mobile cache from the Mobile API.

I think our fallback position is to either run the app from outside the browser area in the existing app or deal with the intermittent connectivity outages.

I read in another post where you talked about the WPF/Silverlight API intercepting the calls to the server to see if there is already a local version of the data, but i am not real clear on how to do this ... would love some further info on that if you have it! 😉

thanks!
david

Re: XBAP in IE

RyanCoodey — Thu, 24 Mar 2011 00:23:51 GMT

David,

We are using XBAPs with IE, but not disconnected (so can't help you there)... We started off with Silverlight, but then for a few reasons moved to WPF:

1) We could use functionality in custom .NET libraries we already have.
2) We want to embedd the maps in other windows applications, and have bi-directional communication between them, so we can just as easily compile as a stande alone app too.
3) Plus having full .NET availalbe is nice :).

But other than a few layout/graphical glitches that were fixed by tweaking the controls template... they work great! Also found a few issues with touch screens, for example with the legend control, the scroll bars intercept the touch and do not pass down to its child controls (like a slider bar), and this issue does not exist in SL.

But all in all, works good for us. But we started when SL3 was out, and as SL keeps getting more robust with every version, we might have to switch one day.

Anyway, hope that helps a bit, sorry I can't comment on working disconnected.