posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

public static IEnumerable<T> QuickSort<T>(this IEnumerable<T> input) where T : IComparable<T>

{ 
            var first = input.FirstOrDefault();
            var result = (from current in input.Skip(1) 
                    group current by first.CompareTo(current) > 0 into grouping

                    select grouping).GroupIntoBool(); 
                    return !input.Any() ? Enumerable.Empty<T>() : 
                            result[false].QuickSort().Concat(input.Take(1)).Concat(result[true].QuickSort());

} 
 
public static Dictionary<bool,IEnumerable<T>> GroupIntoBool<T>(this IEnumerable<IGrouping<bool,T>> input)

{ 
                     return (from bools in new List<bool>() { true, false } 
                                 join grouping in input on bools equals grouping.Key into joinedgroup

                                 select new 
                                 {
                                       val = bools, 
                                       rest = joinedgroup.FirstOrDefault() ?? Enumerable.Empty<T>()

                                 }).ToDictionary(a => a.val, a => a.rest); 
}

posted by cdwatkins

posted by cdwatkins

Also intresting to think about this in terms of a UI framework.  Where the framework itself has one giant IObserable which sends a new value every time the mouses moves or keyboard is pressed, and it hands off to all its children .Where(...) verions of the giant IObserable that filter for just its selected area of the screen or currently selected child (which then wraps its children in another .Where).  In the end you dont need to even test do any hitbox testing or anything, everything just flows down stream.  I spose most UI frameworks like WPF already do this with thier visual tree's just invoking methods on a child of a known type (like UIElement), but when you look at the 100's of On... overrideable method calls, you got to wonder if filtering only what you need might be a better option.  Where they dont have to keep extending the base class to add additional method calls, and instead add new derived event types that return more specific infromation if you want that extra info.  Or say your a team like Microsoft Surface that has some specific type of "new" interaction events you want to pass to your children based on specific proprietary hardware.  In the current WPF, this is very hard/impossible (I think they derived thier own UIElement type and force all thier children had to derive from that to get the new events).

posted by cdwatkins

well IEnumerable is basicly the creator of the object expressing you should (or must if you dont split off a diffrent thread), block while you wait for the result.  IObservable says you "may" block or not block as you wish.  The nice thing about IEnumerable is it expresses that the author doesnt expect it to take too long to get the next value, although even this kind of assumption can be broken slightly.  Look at Linq to Entities or Linq to SQL, both of these take a long time to get all thier values the first time.  Why should the program have to block while it waits for these to finish?  I think IEnumerable will still probably exist for some "in-memory" very quick things, that blocking doesnt really matter on, but I wish there was a better way for authors to express that they dont expect it to take long to get the values then use a totaly diffrent type.

Basicly IEnumerable is sync with a method call to get the result, and IObserable is async with a callback to get the result.

posted by cdwatkins

In the end why don’t you just convert ALL IEnumerable’s over to the IObservable pattern (as well as all events)? (I know that you have backwords compatibility issues with this, but other then that)

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

First you set a property on your usercontrol.  Any property on the user control well be settable in the designer if blend knows how to display its type (such as a string/enum/color etc.).  Then you databind the grid to the usercontrols property.  So you would write something like this in the xaml for the user control: <Grid Background="{TemplateBinding Background}"/>.  You will probably want to make the usercontrols background property be a dependancy property, so that other people can bind data to it (although making DP's are a little more challenging go look it up).

2) How, in c#, to set the Margins of a control?

If I remeber right you get a refrence to the control (such as by its ID), and then just type myGrid.Margin = new Thickness(60);  Thickness has several diffrent overloads if you want to set each side diffrently.

3) I have a SL3 project am testing.  Can't seem to get other browsers (i.e. non-dev) to install the SL control.  Is this because you need to install the SL dev on the client first?  Or should it just download and run SL3beta normally.  Do I have to wait for RTW to have other clients be able to load SL3?

SL3 as far as I am aware does not have a go-live license yet.  As such they have only released the developer's runtime.  The user must have the SL3 runtime already when it starts to have it work right.  The reason for this is they didnt want people getting "autoupgraded" to SL3 if SL3 had a bug.

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

I know in the VS2010 beta released yesterday I got the error "interface members cannot have a definition", so I assume its some latter version of .NET?

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins

posted by cdwatkins