this discussion continued on the rx forums
where a neater solution was found

-end edit-

Hello again, i wrote a little helper class for converting dependency properties to Observable, im not sure its the best way to do it though, what do you guys think? am i missing something? There are some anonymous Observable/disposable in rx that i'd liked
to use but they are internal.. i suspect there is something smarter i can do with the Create methods but i coudnt get around making a helper class..

The nice thing is that the returned observable respects all the rules of Dependency properties, if the dp is changed by a style, trigger or binding, the Observable should reflect that (ive only tried with bindings though)

Rx is a general purpose library, should work fine in asp.NET, just make sure you don't set the Observable.Context to a UI context (the default context in .NET 3.5 SP1 & .NET 4 Beta 2 is the Reactive EventLoop which should work fine for ASP.NET).

Twas the night before Christmas, when all through the house
Not a creature was stirring, not even an observable.
The context was set by the chimney with care,
In hopes that a subscription would soon would be there.

I tried it out and it seems that the anonymous functions in VB are getting in the way. If you write it without anonymous functions then it works fine. The reason is that assignment is a statement and so cannot be an expression and therefore not in an anonymous
function. Instead, the = becomes the equality operator so each time the interval fires it checks to see if the form's text is equal to the current textual representation of the interval's value: obviously wrong.

It gets worse, that is an illegal cross thread call. So, I have to either disable checking, or have a private field and invoke some update method. Or, maybe this is a side effect of running the app in x64 in the debugger. Either way, this is not good.
I thought of overloading the = operator, but that is even more confusing.

EDIT: It looks like I'll have to eat my hat. That function should be a sub. Or did I just stumble across something completely different? That's why I love tomorrow, because tomorrow is another day! I'm going to bed.

EDIT: I just ran it on 2010 and noticed that the thread that hits foo is a worker thread.

Unfortunately, it has nothing to do with Rx. And if you reported it as a VB bug then the VB team would correctly say that it is by design. Which probably means that it is a bug in the user code.

Now, understandably this is a rather confusing bug, and I tend to think that overloading "=" to be either relational equality or assignment leads to some rather interesting cases and so I personally think that VB is rather confusing here.

The code as shown in the screen cast does not work as others have commented because Observable.Context has been removed. Would it not make sense to repost the screen cast reflecting the changes to the API to avoid causing pain to all who look at this screen
cast and find that their code is broken?

OnCompleted on each observer. It has to create this copy because the OnCompleted method is followed by an automatic call to Dispose.

[This automatic call happens only when we subscribe to the output of a LINQ method such as Select etc, and not directly subscribe to the

LocationTracker object (the original observable).] And Dispose removes the observer from the observers collection, so we get the exception “Collection was modified; enumeration operation may not execute.” on the next iteration in the foreach in OnCompleted.
To prevent this the MSDN example uses a copy of the observers collection.

The problem with this approach is that an unnecessary copy is created solely to facilitate removal of the observer from the collection member variable. However, notice right there that the last line of EndTransmission is a call to observers.Clear(). So why
not leave the work of clearing the collection to the observable class and you (the RX framework) avoid making the call to Dispose internally? That way we wouldn't have to make a copy of the observers collection and at the same time be able to use foreach in
EndTransmission.

The observer class here (LocationReporter) has one string member variable instName (apart from the Unsubscriber reference). Making copies of a large number of observers makes that many unnecessary copies of these member variables. Since (from your videos)
the sole purpose of Dispose here seems to be unsubscribing, we don't need to call Dispose here because the mass unsubscription is anyway achieved by the observable when it calls observers.Clear() in EndTransmission.