This post originated from an RSS feed registered with .NET Buzz by Ashish Shetty. Original Post: User-initiated operations in Silverlight Feed Title: Even a chimp can write code Feed URL: http://nerddawg.blogspot.com/rss.xml Feed Description: Ideas on software and elsewhere by Ashish Shetty: erstwhile chimp and occasional re-inventor of the wheel. Latest .NET Buzz Posts Latest .NET Buzz Posts by Ashish Shetty Latest Posts From Even a chimp can write code

1. must be initiated by the user via an input device like keyboard, mouse or accessibility client...
2. ...within Silverlight
3. have an in-built timeout
4. have atomicity of transaction
5. cannot be marshalled across the specific Silverlight plugin's boundaries

#1 is obvious.

#2 isn't. Silverlight will not honor user-initiated operations that start from an HTML element, have a JavaScript handler which calls into a Silverlight scriptable API or other such endpoint.

#3, the in-built timeout in a user-initiated operation exists to eliminate long running, blocking, iterative, recursive tasks within one user-initiated method call. The timeout value is sort of a magic number, chosen to be small enough to no be a pain point for most developers and their scenarios, and large enough not to compromise on its goals.

#4 indicates that you cannot combine two operations in Silverlight which both require user initation into one transaction.

#5 means that the user-initiated "bit" doesn't traverse the Silverlight plugin boundaries, via IPC calls such as local messaging or even intra-process calls via DOM bridge or Scriptable object features.

These may look like quirks but are actually "features" that exist in Silverlight as secure defaults and to provide consistency of behavior across its supported browser and platform matrix. It is important for every Silverlight designer and developer to understand these nuances.