This Blog


Favorite Posts


August 2006 - Posts

  • Thinking about accessibility

    Time again I think for you to take another look inside the CTO's brain to see what he's considering for the next major version of DXperience, 6.3. (Yes, I know, DXperience 6.2 is not quite out of beta, but we've got to consider the big picture here, so bear with me.)

    Thanks to everyone who responded to my previous thoughts about exceptions and about support for VS2002. Your comments were extremely valuable, and suffice it to say, I'm going to push for a much better exception handling story and for dropping VS2002, preferably using latex gloves with the latter so I don't get contaminated with it.

    This time I want to think about accessibility and Section 508. My thoughts here also apply to our Delphi VCL products, so wake up there at the back!

    Section 508 is a clause in the Rehabilitation Act to "require Federal agencies to make their electronic and information technology accessible to people with disabilities." Furthermore, "[t]he law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508 (29 U.S.C. 794d), agencies must give disabled employees and members of the public access to information that is comparable to the access available to others."

    In other words, if you sell your software to a Federal agency, it must comply with Section 508. The Feds have a lot of money, so selling to them is attractive, so it's worth making the effort to make your software accessible to people with disabilities. Since Section 508 also applies to Federal agencies when they develop their own software, presumably with third-party UI components, we, Developer Express, are also paying attention.

    Luckily for us, Microsoft have done most of the heavy lifting. They provide, as part of the operating system, tools like the Magnifier, the on-screen keyboard, and the Narrator (this speaks text from the application you are using). You can access these tools from the Accessories | Accessibility menu from the Programs menu. They're pretty basic, but other companies produce better, more full-featured applications.

    There are other features like a high-contrast color scheme and sticky keys. Vista is much improved in this area too: it has the "say what you see" feature, so that you can drive an application by reading out loud the various options on the screen and the mix of speech recognition and accessibility means that the option you speak is activated.

    So, it pays to program for accessibility, right? Well, yes, but. Whaddya mean, but? Well, there's Vista, you see.

    Windows comes with an accessibility API, which can be thought of as being in two parts. There's the API you need if you are going to write a screen magnifier, a text to speech program, and so on (Microsoft call this MSAA, Microsoft Active Accessibility), and then there's the API you need for your controls so that they can respond to accessibility events (Microsoft call this UI Automation).

    Pre-Vista, both of these were COM-based APIs. Yummy, but when the going gets tough, DevExpress get going. Vista, though, via WinFX, makes UI Automation part of a managed framework. Oh joy. And being as it's WinFX, it's a .NET 2.0 managed framework (well, OK, .NET 3.0). Oh double joy.

    Yes, once again, we have a problem of backwards compatibility and what to support.

    So, a question for you all. Are you using our accessibility support now in your applications? Do you plan to? If your plans are in the future, would a .NET 2.0-only solution suit you? If you use our support at the moment, what if we froze it as it stands, and put all our efforts into the WinFX accessibility support? What about the Delphi crowd? Do you miss not having accessibility support in our VCL components?

    I warn you, this time, the situation, and hence the decision, is not so cut-and-dried. Whereas before I knew what to do, this time I'm not so sure.

    (Aside. I forgot to mention the first time I posted this: Raymond Chen talked about accessibility being for everyone today.)

  • More thoughts about moving forward

    We're getting close to releasing version 6.2 of DXperience and the .NET component sets (if you're a DXperience customer, you can already download the beta from the Client Center). Of course, as we drive to fix the last bugs and polish the last paint method, we're thinking ahead to version 6.3, some 4 months away (we're sticking to a schedule of 3 major releases every year and if we get good at it, next year we'll manage 4), and what should be in it.

    My post yesterday stirred some discussion within our .NET component teams, as well as among our customers. It seems that Visual Studio 2002 (VS2002) is rapidly becoming the black sheep of the Visual Studio family: the component teams are saying that their coding and testing time is increased when VS2002 is factored in.

    Well, duh, say I, of course it is, it's an extra IDE to test. Hello? And then I'm led by the hand into the shadowy world of serialization issues, designer differences, undo problems, etc.

    I wonder how many of you, gentle readers, actually still use VS2002. I'm willing to bet it's a very small proportion. Then, of course, I wonder how many are using VS2003, and, if you are, what your timetable is for moving to VS2005. Or even better, whether your timetable decrees jumping straight to Orcas (Visual Studio 2007), leapfrogging VS2005 (after all, .NET Framework 1.1 is becoming fairly ubiquitous, whereas version 2.0 is still ramping up). And, of course, I wonder how many people are using VS2005.

    Questions, questions.

    My thinking at the moment is closing in on making our current major versions (or the ones about to be released) across the product line the last ones to support VS2002. We certainly can't drop .NET 1.1 and VS2003 support because I sense that there are a lot of people out there who have significant code bases for .NET 1.1 and hence are still using VS2003. The only exception to this rule is ASP.NET, where ASP.NET 2.0 is so much better than 1.1 that you should be using it right now for your web applications (and our new ASP.NET controls are ASP.NET 2.0 only).


  • Driving the IDE tools forward

    I was chatting to the IDE tools team the other day about where we were and where we want to go. CodeRush and Refactor! Pro 2.0 are amazing products that have been well-received but, as I was working on some C# code last night, there's still a long way to go for both of them. For instance, with Refactor! Pro we are only just starting to explore refactorings that affect multiple files (say a rename of a public class).

    (By the way, if you haven't seen this video yet of the new stuff in Refactor! Pro 2.0, you might not know about the Rename public types option that's available as an "early experience" feature. Go to DevExpress | Options, select Editor\Refactoring\Rename, and then check the box and click OK. Now you are able to rename public types. Please let us know via the usual channels if you find any issues.)

    So for example last night, I was working away using Visual Studio with CodeRush and Refactor! Pro, and I'd written some code like this:

        public void FlagDeleted(ListNode node) {
          NodeState newState;
          NodeState oldState;
          do {
            oldState = node.state;
            newState = new NodeState(true, oldState.Next);
          } while (!node.CasState(oldState, newState));

    as part of a LinkedList class when I realized that the code didn't have anything to do with the linked list, but, instead, had everything to do with a node (the one being passed in, in fact). The method should have been part of the ListNode class instead:

        public void FlagDeleted() {
          NodeState newState;
          NodeState oldState;
          do {
            oldState = state;
            newState = new NodeState(true, oldState.Next);
          } while (!CasState(oldState, newState));

    Fowler refers to this as Move Method.

    Now the point of this is not to say, woo-hoo, I've discovered a refactoring we should have in Refactor! Pro (in fact, we already know we want to do this one, but it generally involves multiple file updates and we don't do those very well yet -- witness the early experience Rename functionality), but to show that there is still a long way to go and normal programming brings up examples like this quite quickly.

    And that brings me to another point. Currently we support Visual Studio 2002, 2003, and 2005. When we began integrating the VSIP interfaces into DXCore (VSIP is Microsoft's COM API into Visual Studio), Microsoft’s primary interop assemblies (PIAs) weren't available. So, we translated the interfaces that we needed into C# and created our own interop assembly. Eventually, of course, Microsoft released their PIAs, but built them under .NET Framework 1.1. They are a mite temperamental to say the least when loaded in VS2002, so we essentially ignored them in DXCore.

    Unfortunately, the release of VS2005 moved the goalposts. VS2005 introduced a lot more managed packages to access the new XML language service, the improved project system (much needed for multi-file refactorings), Team System stuff, SQL integration, etc. And they all use Microsoft's PIAs. So, if we stick to our interop assemblies we can support VS2002; if we switch to the official PIAs we can no longer support VS2002, but we get the benefits of much better integration with VS2005 and, a bit later, Orcas (and Orcas and .NET 3.0 are not that far away).


    In essence, to move forward, to be able to support more of the things we should be implementing (and want to implement), we have to strongly consider dropping support for VS2002. Now, I'm sure that the vast majority of our customers don't use VS2002 and have already moved to VS2003, and maybe even VS2005. VS2002 is getting long in the tooth and VS2003 was, frankly, a major improvement; similarly .NET Framework 1.1 and 2.0 have some great enhancements over .NET Framework 1.0.

    So, I would like to give some warning that, although we'll be supporting VS2002 over the short term with minor upgrades, I think the next major version of the IDE tools is likely to only support VS2003 and VS2005.


  • DXCore: more wholesome goodness

    It's not generally known but we make DXCore, the base software that both our CodeRush and Refactor! Pro products use, available as a free download. Essentially, DXCore wraps the somewhat-difficult-to-use VSIP interfaces in a neat .NET package with extensibility points, and also provides some extra functionality for Visual Studio available nowhere else. Using DXCore, you too can make some rather nifty tools for Visual Studio that use the same visual effects we use in CodeRush and Refactor! Pro. We provide some documentation for this, but we also have a very active newsgroup for DXCore on our server, and there's even a community site that supports development using DXCore.

    Just the other day I learned of a new DXCore plug-in that sounded very intriguing, something that I hadn't thought of, or, if I had, it hadn't really registered. Joel Fjordén has implemented a plug-in for DXCore that checks compliance against coding standards. Now, to me, coding standards are a bit of a bête noire: in my previous job I wrote the coding standards that the development organization were supposed to follow, but that were pretty much ignored. It almost seems that if you put fingers to keyboard in an IDE, you automatically have your own coding standards, so the thought that someone had written a plug-in that checks for adherence to some departmental standard was very interesting.

    Anyway, I was interested enough to ask Joel what prompted him to do this and how he'd fared and he was gracious enough to answer. Thanks, Joel!

    ctodx: What made you use a DXCore plug-in for your coding standards checker rather than say a console app that batch runs through the source files at check-in?

    JF: Well, first I thought about doing a stand-alone application, but then I got the idea of making a Visual Studio add-in instead. I had this idea of having all code style violations end up in the IDE's Error List. I gave up this idea really quickly, since the API for this wasn't that nice and easy to work with. It would simply have taken too much time, without giving me a lot of satisfaction.

    After listening to a podcast on .NET Rocks, I heard about CodeRush and Refactor so I just had to try them out. I was really impressed, especially with the visual experience that these two products use. I then read some more about DXCore and came up with the idea of making a more "visual" code style enforcer, so I suppose "visual experience" is really the answer to your question. As it works now, the user gets immediate feedback when writing code: the code statements that violate any rules are highlighted and the programmer is instantly reminded.

    ctodx: What kind of coding standards are checked with your plug-in?

    JF: There are three types of rules at the moment: name rules, visibility rules, and implementation rules.

    The name rules define valid names for fields, constants, readonly fields, variables, parameters, properties, methods, event handlers, classes, structures and interfaces.

    The visibility rules define the visibility that is valid for different members. It’s also possible to specify that the visibility has to be specified explicitly.

    The implementation rules define that interface implementations have to be made explicitly or implicitly.

    ctodx: How does a coding standards violation show itself?

    JF: The code block that violates a rule is underlined in red. This is a really nice and simple feature that DXCore offers. The nice thing with this line is that it isn't a normal straight line, but instead a line that looks like it has been drawn by hand, which makes it much more appealing.

    There are also tooltips with information about the violation that appear when hovering over an underlined statement.

    ctodx: How often does the checking engine run?

    JF: As soon as code is entered or a code file is opened. The code standard for a language element is actually checked when the event is fired for a language element to paint itself. This means that only language elements that are currently visible are validated.

    ctodx: How easy was it to write?

    JF: It depends on what you compare it with. If you compare it to writing the same thing using the VSIP API, I think it was really easy. The hardest part was to know where to start looking for information. The first breakthrough was when I watched an episode of dnrTV with Mark Miller where he wrote a DXCore plug-in in something like an hour.

    The documentation was rather thin I think, but the newsgroup for DXCore plug-ins has been an invaluable source of information, since it's actually possible to ask questions there and get answers.

    ctodx: How many developers now use your plug-in?

    JF: Right now we have about 10 developers in the current project. Not everyone followed the coding standard before; some did, but they still inadvertently violated it from time to time when not thinking about it. Now with this plug-in all code statements that violate any rules in the coding standard are underlined with red. Suddenly everyone wants to correct it, since nobody want to check-in code that simply doesn't "look nice" when someone else looks at it.

    I personally think that it's very important to follow a coding standard. It becomes more and more important the more developers there are in a project, since there is more opportunity for coding standards violations to creep in, making the code harder to read.

    (Have you built an interesting application with our products? Does it use some unusual feature that we might not have seen elsewhere? Let me know, and I'll write it up here.)


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners