Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


William Kempf wkempf
  • Software changes do not occur overnight!

    thumbtacks2 wrote:

    Tim Sneath wrote:
    To be fair, the goal of the tutorial is not to lead you through the steps to produce Outlook in the minimum number of pages, but rather to provide a comprehensive learning guide to our designer and developer tools while building a fun and useful sample.

    (And that's not to say that building an Outlook-like interface is a trivial task, either - particularly if the controls are real, working, data-bound controls. I'm sure it was significantly more work for the Outlook developers to build this code in Win32.)
    I suppose the logic here is that "in the era of 1,000+ page programming books, what's another 90 pages?"

    Out of curiousity, how hard is it to write your own WPF controls anyway?

    The first thing to learn, is that you hardly ever need to write your own controls.  Templates, styles, attached properties and markup extensions can all be used in creative ways that replace many of the reasons you'd create a custom control in other frameworks, such as WinForms.  Like I said, I've made use of ListView and GridView several times for things that would have required a DataGrid in WinForms simply by applying a little bit of styling and templating.  It's really quite amazing what you can accomplish here with out creating a custom control.

    If you do need to create a custom control, it's extremely easy.  Much easier than in WinForms where control compisiting requires a lot of grunt work and painting of controls is tedious and difficult.  In WPF, your control class cares only about functionality, since the controls are "lookless".  That's extremely easy to do.  Then you provide a default template for the control, which can easily be crafted by compositing and using builtin presentation features.

    There's a learning curve, and there's still some areas I think need some help, but in the general cases this stuff is really quite nice.

  • Software changes do not occur overnight!

    vesuvius wrote:

    I have been 'meddling' a little with WPF at long last, and am in all likelihood going to Echo what has been said before. As a one man band, I’m continually looking for utilities that will increase my productivity, but not at the expense of quality. It’s for this reason that I see the acquisition of controls from http://www.componentone.com/, http://www.telerik.com/, http://www.componentfactory.com/, http://xceed.com/ et al, as (this will come as a surprise) essential in the speeding up the development process.

    Personally, with WPF's lookless controls, I've found it rather unnecessary to use 3rd party controls.

    vesuvius wrote:

     After (eventually) traipsing through a tutorial at http://blogs.msdn.com/tims/archive/2007/06/13/wpf-hands-on-lab-build-an-outlook-2007-ui-clone.aspx I’ve come to the realisation that you’re either a designer or a programmer (shock horror). Linq may increase productivity, but this is voraciously negated by the amount of time it will take to get your UI right in Expression Blend and Visual Studio. All the companies above have little to no components that are ready (bar the lovely data grid view from Xceed – it’s simply gorgeous) . Why should I have to undertake the task of writing a scheduler (calendar) just because I need one for my app. WPF doesn’t even offer a data grid view in its present iteration, honestly?

    The vast majority of the use cases I've had for a "data grid view" have been easily worked up using ListView with a GridView and some styling.

    The productivity comes from the unbelievable data binding.  Not a designer?  Follow the M-V-VM pattern religiously and slap together an ugly UI, then let a real designer make it pretty.  Honestly, the data binding capabilities make it possible to realize a "lookless" application that can be "painted" by a designer with little effort.  Of course, the ViewModel should be designed with some UX thought up front, so I'm not advocating completely ignoring the designer until the end.

    The premise of WPF was never to eliminate the need for both developers and designers (some people do successfully wear both hats), but to make the efforts of the two seemless and more efficient.

    vesuvius wrote:

    Working through the Microsoft Acropolis projects, that is as immature as WFP (well it’s based on it). The idea though is an excellent one but the level of immaturity of WPF and the unavailability of R.A.D components from Microsoft (no data drid view) or other vendors makes this something to get excited about in a while. Just not now, that’s all!

    These technologies are brand new.  Expecting anything other than this is foolish on your part, and a rant about it is misplaced frustration.

    That said, once you can get over the incredibly large learning curve, I'm find WPF to be an incredibly exciting technology that does allow me to be very productive.

  • OWL Lives On

    *chuckles*  The web site claims a disadvantage of OWLNext is that it's OpenSource.  Great way to ensure no one will use it, making a claim like that.

  • LINQ Question

    SecretSoftware wrote:
    Error    2    Property or indexer 'AnonymousType#1.MyAnnoymousP' cannot be assigned to -- it is read only  

    Why did this became like this as we go from Beta 1 to Beta 2?

    This code generated the above error

    var q = from x in y
                 where x.d = 1
                 select new {MyAnnoymousP = x.L, x.J};

    q.MyAnnoymousP = Something;

    in beta 1 this was valid, but in Beta 2 it became ReadOnly. Why? Will this change? Is this a bug in Beta 2?


    littleguru gave a good answer, but I'd like to point out that your code above has several bugs and won't even compile.  I realize this is example code typed on the fly, so I'm not trying to be a "code cop", but until I read the answer from littleguru I couldn't even figure out what you thought was wrong. [C]

  • Moonlight is the official Silverlight ​implementat​ion for Linux!

    Chinmay007 wrote:
    intelman wrote:
    They should implement Silverlight at soapbox, and offer all HD resolution.

    Microsoft should really drop use of Flash altogether if they are serious about this stuff. Lets see everything interactive (sans HTML) throughout Microsoft's part of the web implemented with Silverlight/Moonlight.

    Replacing existing instances of Flash isn't productive.  However, from this point forward I'd hope Flash would be avoided.

  • Moonlight is the official Silverlight ​implementat​ion for Linux!

    Bas wrote:

    Can we please keep the Silverlight posts in a single thread?  There are four of them on the first page right now.

    1.  Post police drive me nuts.

    2.  That thread, though it mentions Moonlight, is about the Silverlight release.  This thread is focusing on Moonlight.  I don't see them as identical threads.

  • Moonlight is the official Silverlight ​implementat​ion for Linux!


    All I have to say is wow!  I know there's a lot of people out there who are going to attack this ferociously from every angle.  After all, it's Microsoft, Novell and Mono, three entities that the OSS zealots love to attack.  But still, I'm impressed by Microsoft's move.  Instead of creating their own implementation that would compete with Moonlight, they actually endorse Moonlight as the OSS solution, and provide the needed collaboration to ensure compatibility.  Bold move, and I think the people in charge of all of this deserve some kudos!

  • Philosophic​al INotify​Property​Changed question

    bdesmet wrote:
    It's a good question indeed but I do have a few concerns with the design of the properties you're describing. If setting one property causes another property's value to be changed as well, this is pretty much to be considered as a side-effect and maybe a property isn't the best choice in that case (in more complicated situations you'll have to make sure you're not causing a cycle in the chain of setter calls). For more info, check the Framework Design Guidelines on Choosing Between Properties and Methods.

    Nevertheless, there's no silver bullet to this kind of problems - the one thing that's key is to be consistent. Concerning your WPF sample, I'd rely on the SelectedWidget property to become null automatically.

    There are a million reasons properties would behave the way I described.  Some simple examples:

    DueDate and DaysPastDue.  These are variations on the same data.  A change to one thus is a change to the other.  With little thought you can think of a lot of other examples that fall along these lines.  For example, think of a Rectangle and the correspondance between the corner coordinates and the width and height.

    When following the M-V-VM pattern, you'll typically have (for example) a Widgets collection and a SelectedWidget.  A change to the Widgets collection can effect the SelectedWidget property.  Those are just a few examples.

    I'm not denying these are side effects, I'm denying the assertion that properties shouldn't have side effects.

  • Philosophic​al INotify​Property​Changed question

    Obviously the order should matter Wink.  But even from your description, I'm not certain that you've got the right order.  Part of changing A is changing B.  That means that B gets changed first.

    I didn't want to spoil the discussion by stating my own thoughts, but maybe I should just spill it Wink.

    I think that setters should first ensure that all invariants are maintained, which means that events should probably fire after all changes to the object's state have been made.  If that's the case, the order in which they fire is irrelevant at the source (the object), and only relevant at the target (the event listener), and it's wrong to assume any order at the target.  Despite this, I think you should probably fire the events in the order in which the changes complete, so B fires before A.

    This is a simple thing, that only in corner cases will probably be of any real concern.  But it's the sort of thing always left out of consideration that gives me heart burn. Smiley

  • Philosophic​al INotify​Property​Changed question

    Imagine you have an object that implements INotifyPropertyChanged.  One of the properties, say Foo, can be modified which will in turn modify another property, say Bar.  In what order should the property change events fire (Foo followed by Bar or Bar followed by Foo), and why?

    Somewhat related, let's imagine we're writing a ViewModel for our WPF application.  We have a Widgets property and a SelectedWidget property.  If we reassign the Widgets property, the WPF databinding will indirectly cause our SelectedWidget property to be set to null.  Should be rely on this fact, or explicitly set the SelectedWidget to null in our Widget setter (which might (will?) cause a harmless redundant call)?