Vista - API Standards question: FrameworkElement.Focusable

Does anyone know why FrameworkElement.Focusable is not IsFocusable for
consistency with the rest of WPF? I only noticed this recently (mainly
because I've only just started messing with it but never realized it wasn't
in the Is* group in autocomplete) I imagine there are other cases where
this is true, but I haven't run into any that I recall.

Yeah, in a better world, it probably would be called IsFocusable. We've
tried to follow all the managed code naming guidelines, and got most of
them, but we obviously missed this property. But one of the things we've
noticed is we can spend a near infinite amount of time tweaking the APIs,
and after a certain point it doesn't add as much value as the other work its
crowding out, and costs people a lot of time updating their programs with
each new CTP, so we've tried to really ratchet down the number of API
changes we're making.

-Nick Kramer [MSFT]
http://blogs.msdn.com/nickkramer

---
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Keith Patrick" <richard_keith_patrick@nospam.hotmail.com> wrote in message
news:u15EQToNGHA.964@tk2msftngp13.phx.gbl...
> Does anyone know why FrameworkElement.Focusable is not IsFocusable for
> consistency with the rest of WPF? I only noticed this recently (mainly
> because I've only just started messing with it but never realized it
> wasn't in the Is* group in autocomplete) I imagine there are other cases
> where this is true, but I haven't run into any that I recall.
>
>

So you're OK with having ground zero of the framework being inconsistent
with the rest of the API (and MS API "standards") so people don't get
compilation errors using a CTP? This is version 1, AND a CTP, so if not
now, when?!?!? It's not like catching a compilation bug like that is a huge
chore (well, unless you use the VS2005 refactoring, which is godawfully
slow, but CTRL-SHIFT-H should suffice), or it'll break explorer.exe, so why
not make it consistent *before* the API has gone gold? It's not like anyone
is going to be surprised by a CTP introducing a breaking change (and I've
gotten breaking changes in my UI that have taken orders of magnitude more
time to track down and fixed than a simple compilation error)

Keith Patrick wrote:

> So you're OK with having ground zero of the framework being
> inconsistent with the rest of the API (and MS API "standards") so
> people don't get compilation errors using a CTP? This is version 1,
> AND a CTP, so if not now, when?!?!? It's not like catching a
> compilation bug like that is a huge chore (well, unless you use the
> VS2005 refactoring, which is godawfully slow, but CTRL-SHIFT-H should
> suffice), or it'll break explorer.exe, so why not make it consistent
> *before* the API has gone gold? It's not like anyone is going to be
> surprised by a CTP introducing a breaking change (and I've gotten
> breaking changes in my UI that have taken orders of magnitude more
> time to track down and fixed than a simple compilation error)

Have to jump in with a +1 on this one. It's not like it's a serious change
to the architecture, it's a simple find and replace for developers who should
expect stuff like this when working with a Beta/CTP product.

Just my 2¢,
Drew
___________________________________
Drew Marsh
Chief Software Architect
Mimeo.com, Inc. - http://www.mimeo.com
Microsoft C# / WPF MVP
Weblog - http://blog.hackedbrain.com/