This Blog


Favorite Posts


November 2007 - Posts

  • Hey, dude, like where's my Visual Studio 2008 support?

    UPDATE: DXperience v2007 vol. 3.4 (2007.3.4) has now been released with full support for VS2008 RTM, rendering this particular post moot.

    In the interests of future historians though, I'll leave it up.

    Well, OK, we haven't got any emails quite like that yet, but I thought I'd throw up a quick blog post to say what we're doing now that MSDN subscribers now have the RTM build of Visual Studio 2008.

    The first point to make is that we got our copy of Visual Studio 2008 RTM at exactly the same time as everyone else. We have to download and install it just like you, and then we get to load our various projects (products, test code, installs, etc, etc) and compile, run, and test it all. We need to do this and do it well, otherwise you, our customers, could get some very nasty buggy code. We can't assume that just because something worked in VS2005 or in one of the betas for VS2008 it's going to work just fine in the RTM of VS2008.

    So, as of this morning, we're seeing several issues.

    • There's been some installation problems with Visual Studio 2008. For example, we've run into the same problems as this guy. One issue we've solved is that VSTO (Visual Studio Tools for Office) can interfere with the VS2008 install and you need to uninstall it first. A couple of people are also reporting issues with running VS2008 and VS2005 side-by-side.
    • There is some bizarre behavior in CodeRush and Refactor! Pro where Intellisense is not coming up. Got to solve that one of course. (Already solved: I was reading old internal posts.)
    • The XtraCharts team have discovered a doozy of a problem: the WebChartControl can no longer be dropped on a form from the toolbox. (They've narrowed it down to any custom control that is implemented in two assemblies, with the same namespace used in both assemblies. If you create such a control, drop it on the form, it's created with the wrong prefix (ccl) and so is created with errors.)

    And those are only the issues I've got to learn about in the last 24 hours. I dare say there have been others that have been solved without me being in the loop.

    So, yes, we're working hard on getting minor releases of our products that support the Visual Studio 2008 RTM out as soon as possible. Stay tuned for more developments.

    It doesn't help that tomorrow is Thanksgiving... Sigh.

  • XAF bootcamp: Defining the business problem

    (See this post to see what this is all about and to set the stage.)

    I had an enjoyable chat with Kelly last Friday about the problem that she needs solving. Also present in the interview was Larry, the IT Manager for the District Attorney's office, who was very interested in the eXpressApp Framework (XAF) technology I would be using.

    Kelly leads a department of 13 staff, of which 6 are Victim Advocates. Although the department comes under the aegis of the DA's office, legally it's separate. They are there for the victims of felony violent crime (for non-US readers, a felony crime is one that will generally involve jail time if found guilty, whereas a misdemeanor crime will usually just involve fines and/or community service and other such), vehicular homicide (that is, a driving accident involving death, sadly most often also involving alcohol), and domestic violence. They also deal with victim compensation to aid with medical bills and the like arising out of the crime, and restitution for victims from convicted criminals. The Victim Advocates provide victims with information on the criminal justice system, court case updates, referrals and court accompaniment, as well as emotional support. Having watched my wife, who's a Senior Deputy District Attorney, prosecute a couple of nasty cases involving child victims, I can well attest to the work these Victim Advocates do.

    It seems that the DA's office here in El Paso County deals with about 5000 felony cases a year, and the Victim/Witness Section gets involved in about 2000 of them. The staff at the DA's office make well over 6000 contacts (mostly phone calls, but also face-to-face meetings, emails, and letters) with the victims of these cases, say about 3 contacts per case. Kelly does note though that the current system that tracks all this is not 100% reliable so there may be other contacts being made that are not getting tracked properly. Anyway, it does give us a sense of the scale of the data input and reporting.

    According to the Colorado Victim Rights Act, departments like Kelly's must log and report on the number of victim contacts made by their associated DA's office every year. These numbers must be broken down in various categories, for example by date range, by the type of crime, and so on.

    In chatting with Kelly, I made lots of notes about the goals she needed to attain, and how the current Access system didn't fulfill those goals, resulting in extra manual work for the staff in the department. Back in my office, I made an attempt to work out the various entities and attributes that my notes exposed. I'm using a pretty standard methodology to analyze my notes here to build up an entity model, but one of the things we're seeing already with XAF is that some developers haven't had the training or experience to understand how to do this formally. There are several books that describe how to distill an entity model (or a domain model, if you follow the Domain-Driven Deisgn methodology) out of a series of interview notes, and I'll have to write a post that describes those I've used in the past.

    If you get the entity model wrong, it's not the end of the world when using XAF, but it can make things a little more difficult later on. So bear with me as I describe what I found.

    Rereading my notes, I identified several things or entities that I should track in the new system. The four big ones, if I may call them that, are: Victim, Defendant, Case, and Contact.

    A Case embodies the DA's view of the crime. Although there can be an awful lot of information related to a Case (such as police reports, medical reports, motions, evidence lists, and so on, so forth), for this system we can get away with just a few basic attributes. The most important one is the victim, of course, but Kelly did note that sometimes there may be more than one victim in a crime, so we'll need to maintain a list of Victims. Next up is that a Case has a defendant. Again usually there's one such but sometimes there may be more than one. There is an exception to the rule here as well: in the very early stages of a case, the crime has been committed and we know who the victim is, but there may not be a defendant yet. Maybe the police are still trying to identify one, but that doesn't mean that the victim won't be contacted. I've already mentioned in passing that a Case must be of a certain type (say, Domestic Violence, Vehicular Homicide, etc). There's also a small set of attributes we'll also need to track as part of a Case: the court division it's in, the DA in charge (this can change throughout the life of the Case, but for this system we only need to track the current DA), the Victim Advocate currently assigned to the case. Finally we need to track the case number allocated to the case.

    A Victim embodies the information about a victim of the crime. Mostly this is the usual type of information you'd store about a person: name, address, phone numbers (there may be more than one), email addresses (ditto). Kelly said she'd like to be able to store some freeform notes about a victim as well. This is something I'm a bit leery about -- there have been systems I've worked on where I was writing reports that selected records based on some values in the middle of such freeform fields, but at the moment I'll go along with the request and have asked Kelly to let me know if she's going to track some particular kind of information that might be better served as another separate field. The Victim also has a list of Cases, hopefully only one.

    A Defendant is pretty simple (by that I really mean the Defendant entity in the system is pretty simple; I'm not making a judgment call on the intelligence of defendants involved in violent crimes): we need to know the name, maybe some freeform notes, and a list of Cases. I'd like to add "hopefully only one" here too, but recidivism is always a problem. Of course, the Victim/Witness Section aren't going to be contacting the defendant any time soon, but at the very least they need to know who it is.

    Finally, a Contact embodies the information about a particular contact made by someone in the DAs office (prosecutor, advocate, paralegal, investigator, etc) to a victim in a case. We need to know: the Victim, the Case, the person doing the contacting (I'm calling this the "contactor"), the date and time of the contact, the type of the contact (email, letter, phone call, etc), and some freeform notes about the contact.

    (We had a little discussion about the "time" part of the contact. It's not currently tracked at the moment, the contact date being the more important part of the data. I made the case that, if I made it easy to enter some kind of time information (for example, not the exact time, but something like morning, midday, afternoon, evening), it might be helpful in the future. We'll see: at present it's not an important part of the Contact entity.)

    From these descriptions, I'm sure you can see lots of other smaller entities that are making themselves known. For example, CaseType, ContactType, Contactor, ContactorType, PhoneNumber, EmailAddress, and so on. And I'm sure that you can identify some of their attributes too (and that some won't have any attributes apart from a name, since they're essentially enumerations).

    Note that, in describing these entities, I'm not describing any behavior for either them or the system as a whole. At the moment, the system is panning out to be a data-driven system rather than a behavior-driven system, but maybe we'll discover some behavior as we proceed through some prototypes.

    Next time, we'll start building the business object model.

  • Putting XAF's nose to the grindstone

    I read Scott Watermasysk's recent post today with some interest (hat tip: Larkware). The post's premise is that if you can't create an "interesting" prototype of an application in 1000 lines of code or less then you are most likely over-complicating things.

    This spoke to me for a couple of reasons. First of all, we're getting close to releasing eXpressApp Framework (XAF). When I say close, I really mean close. Those of you who've been using the current Release Candidate may well be saying, duh, it's ready right now, get on with it already, but in the last three months or so since that RC was released we've been adding some interesting new functionality to make the framework that much easier to use. This new functionality relies in part on DXperience v2007 vol3, and in part on a new iteration of DXCore that Mark's team has also been working on. Although the new version of DXperience is ready to go (and may be released by the time you read this), DXCore is not quite there.

    The changes to DXCore need a blog post of their own (and Mark will be writing one), but in essence we've revamped it to only work on Visual Studio 2005 or later and to have a slightly modified interface so that we can add a new feature called "code providers". It is this latter functionality that XAF uses.

    Of course, in changing DXCore, it means we have to change CodeRush and Refactor! Pro so there's quite a bit of work happening on that front too.

    Anyway, back to XAF and Scott Watermasysk. XAF is a great tool for doing the kind of prototyping Scott talks about. With it, you can very quickly create a working application that shows off a solution to a business problem, and without very much further work provide a full deployable application with the must-haves like proper security and reporting. And pretty much all you need to do is write the lines of code for the business class model. Not many lines of code at all.

    Along with that, Scott's post prompted me to go back to an application I've been meaning to write for a little while.

    Some of you may know that my wife is a Senior Deputy District Attorney for the 4th Judicial District Attorney's Office in Colorado Springs. Like all government offices the country over, the DA's office is strapped for cash and some nice- to-haves and even must-haves tend to get pushed aside for a rainy day. One of the must-haves that the office is required by statute to provide is a system for reporting victim contacts made by the staff (lawyers, paralegals, investigators, etc) in the DA's office. It's part and parcel of Colorado's Victim Rights Act.

    At present this system is a pretty nasty cobbled-together Access database and application that creaks and groans, dies regularly, and whose reporting is best charitably described as laughable. A couple of months back, my wife approached me on behalf of the head Victim Advocate in the office to see whether I and Developer Express could do something about it. They couldn't pay a contractor to do a rework and there was no one internally able to do it or who had the time (the original app was written by someone in-house who had since moved on and who shouldn't have been let anywhere near Access in the first place). Could Developer Express help? And for free?

    Of course we could. I told her we had this new product called XAF (her eyes started to glaze over) that would enable me to write such an application very quickly (her eyelids drooped), and allow the staff to run it either as a Windows program (eyelids now closed) or as a browser application. She was practically snoring at this point but woke up when I said that running the program in the browser was the easiest thing for the majority of people in the office to use since there was no install. Only the staff in the Victim/Witness Section need have the full Windows program.

    To cut a long story short, Developer Express are partnering with Colorado's 4th Judicial DA's office to write an application that will record the staff's contacts with victims of violent crime and vehicular assault in El Paso and Teller counties, the region covered by the 4th Judicial District (it includes Colorado Springs, Manitou Springs,and Cripple Creek).

    I'm going to be writing this application with XAF over the next few days, using the latest in-house version that we demoed at DevConnections. I'll also be blogging about my progress, and this series of blogs will describe in detail how to write and deploy a real-world application with XAF. In the end, we'll deliver a working application to the DA's office and, come to that, any other DA's office in Colorado.

    Stay tuned for the next installment where I interview the manager of the Victim/Witness Section (she's called Kelly) about what she wants out of the system.

  • WPF grid: where the bleedin' edge can be sharp

    One of the things we showed off at DevConnections last week was the latest pre-alpha iteration of our WPF Grid.

    The devs responsible for our snappy ASPxGridView, Andrew and Mike, have been heads down in WPF and XAML internals over the past several months, understanding the platform and seeing how to bend it their will. And, of course, the ASPxGridView occupied some of their time too: witness the changes to appear in DXperience v2007 vol3.

    You may think this is bizarre: an ASP.NET grid and a WPF grid are indubitably very different beasts. Surely we have devs just sitting around playing CounterStrike, eager and ready to take on a new project like WPF? Well, no, actually. Work never seems to stop in the DevExpress labs. Besides which, there are a lot of similarities between writing a control like the grid for ASP.NET and WPF.

    First and foremost, it's all about the visuals. ASP.NET pretty much forces you to that point (the browser is a fairly primitive execution engine and is far better at showing stuff), and it's the whole premise of WPF. Second, it's all about styling: gone are the days of having a control with a bazillion different properties and methods for altering the appearance. Today it's CSS and styling using XAML. Third, it's about reusing the data access components we've already spent a great deal of time implementing, testing, stressing, making rock-solid.

    All in all, Mike and Andrew were the best people we have to do the job. They know grids inside out (Mike wrote the original XtraGrid, the very first third-party .NET control ever released, and the first one with source code too). And what a great job they've done so far.

    Let's see. At present the grid displays record data in a tabular form, rows and columns, with the rows corresponding to records and the columns to the fields of those records. Bog standard stuff. There is already support for unbound fields (calculated fields, if you like). We have sorting and grouping to many levels. It can calculate overall footer-type totals as well as group summary totals. Of course, the grid has the large dataset support we've been talking at length about in our marketing with regard to our ASPxGridView and XtraGrid. Let me tell you, this grid is fast, no matter whether you are sorting or grouping or displaying data from a dataset with many tens of thousands of records. And frugal with memory at the same time. (I seem to recall something in Computer Science that says you can have speed or small memory consumption, but not both. We seem to have broken that rule.)

    And we've spent a great deal of time thinking about and designing for the ability to easily style everything in sight (just look at those rounded corners on the first row of the detail grid as an example). In doing so, we ran into some limitations of the WPF Framework. For example, the ListView class would seem to be the ideal class to use for something like the grid, since it displays items in a list. Just make a template for a row to show the fields and Bob's your uncle, as we say in England. Except it was designed for a small number of items, not for thousands. (We used it as the basis of our jog wheel selector in our demo, for example.) When you load thousands of items into the ListView, you have to create not only the data structures to hold the data, but also the visual elements to hold it all. Massive huge whopping memory usage, that's what happens, and that's before you start worrying about how to style it all. And it just didn't have the number and breadth of styling entry points we wanted to expose.

    Hence one reason we're not at the forefront of releases for WPF controls is that we won't compromise on performance and features just to be first. We also wanted to be quite sure that we designed our grid for the WPF environment and that means giving designers the ability to style the look of the grid, whether though tweaking XAML or using a designer. Writing anything in WPF is a delicate balance between writing traditional imperative code in C# or VB or C++ and writing declarative code in XAML. The end result was that we decided to write our own container element for the grid and not reuse something that's manifestly not up to the job. Er, yes, that would be extra work, but well worth it we believe, even though it takes longer to get the control out.

    So, where do we stand? Well, if you just wanted a WPF grid to display data, we could just about release tomorrow, albeit without documentation and a designer for VS2008 and a bunch of other things. Of course no one really wants just that, they also need the ability to edit the data in the grid. We've already shown that we can style individual cells (see the "check box cells" in the image), and an editor is "merely" just another style applied to a cell. If only it were that easy, but there are a lot of issues still to take care of. Nevertheless, progress on the remaining work (designers, editing, demos, documentation, etc) for the WPF grid is looking good.

    We are also looking forward to getting our hands on the RTM of Visual Studio 2008 so that we can discover, along with everyone else on the planet, exactly what the WPF designers and interfaces (aka Cider) are like and how easy they are to use. I know there's already a designer application out there, but please don't ask me about Microsoft Blend, I tend to froth a bit at the mouth.

    All in all, the WPF grid won't be released this year. Early next is our current in-house prediction. As usual though we do not give out actual release dates so you'll have to be satisfied with that deliberately hedged and ambiguous timetable. I dare say we'll be looking for some beta test sites before release, so if you are a DXperience Enterprise customer and are looking at WPF, drop me a line.

    A word of caution though. It's going to take time for us to create the other controls we have for WinForms on the WPF platform, at least those that make sense. Do not expect us to magically declare a whole slew of WPF controls over the next six months (say). It isn't going to happen. Indeed, we're very much of the opinion that WinForms is not going to suddenly disappear overnight in favor of WPF. It's going to take time for the community as a whole to understand what can be done with WPF, what even makes sense to be done with WPF, how VS2008 is going to shake out, how Blend is going to progress, and so on. Be at the bleeding edge if you want, but we have to balance progress in this direction with all the other directions we're actively pushing forward in.

  • Developer Express does Silverlight

    Actually it's more like Silverlight does DX, but bear with me, OK?

    First of all, check out our Silverlight-powered What's New for DXperience v2007 vol3. This is a simple enough Silverlight 1.0 application, the result of a collaboration between one of our designers and one of the devs. It certainly was fun to do, but in the end was nothing more or less than what could be produced with Flash, for example.

    There's nothing really there in Silverlight 1.0 for us to get a hold of and make a business from. It's more of a designer's platform than a real developer's platform. No, the real fun is with Silverlight 1.1 with the cut-back Framework written in C# and the compiler that compiles it all. Much more developer-oriented this one.

    The issue of course is that all we have is an early alpha. The Framework-lite we have in this release is very, very light. Lots of things are missing, lots of things are very exploratory or not even nailed down. We have no real data on what is slated to appear and what isn't.

    Nevertheless, we did have a little demo of a couple of controls we've been testing the waters with, And if you'd asked me nicely at DevConnections I'd have shown you them.

    Important Sidebar: Our Silverlight controls are not finished. They are not a product yet. They are not for sale; nor have we even talked about how to sell them. We do not have a schedule for releasing them, just as there is no known release date for Silverlight 1.1. We have only really run them in IE7, not Firefox or Safari. We don't know if they work in Mac OS/X. They are not even alpha-ready, let alone beta-ready. They are not vaporware per se, more like steamware: ready to condense when the temperature cools enough. There, I think that covers all the bases :).

    The issue we've found in creating these controls is that the Framework is just too unformed. For instance, there are two classes you can use to create a new control: Canvas and Control. Microsoft would like you to use Control, but even in our rudimentary experiments it's not extensible enough and is too closed. So our controls were built on top of Canvas just so we could get something done.

    The controls we've done are a couple of variants of a layout panel. One's a docked panel that knows how to dock itself to the sides of the browser window (or to each other, if there's already a panel docked there). The other one is a layered layout panel that displays a set of items and knows now to flow them vertically and horizontally. It also knows about resizing events, so that reflows happen automatically. There's also drag-and-drop of the items so that you can reorder them manually. And so on.

    Essentially Vlad, our dev on the project, had to take a whole chunk of our existing code and make it work with the reduced Framework in Silverlight. [Update: he tells me that in fact he didn't, it was easier to rewrite it from scratch.] That was the easy bit, the harder part was coercing Silverlight to his (not inconsiderable) will.

    Anyway, I'll see if I can't get an image to display (I don't have it installed on my machine here).

  • You want unit tests? We got unit tests...

    I've still a great deal to say about our DevConnections experience — and will over the next few days — but I'd first like to announce an initiative that we've decided to pursue.

    Several customers have come to us at the show to ask a specific question: can they get hold of out unit tests for our user interface controls. I must be admit that we've been asked this in the past but for some reason we've prevaricated about it, I can't really recall why now.

    Anyway, that was then, this is now. We've decided to do something about it. As always with this kind of thing there's good news and bad news.

    First the good: we're going to release the unit tests to our .NET user interface controls. This will give you the opportunity to see how we test our classes, some hints on how we expected them to be used, and so on.

    Now the bad, or more accurately, the not quite as good. Although we have functional tests, we don't have complete unit test coverage over all our UI controls. Some controls, especially the more recent ones, are much better covered than others. We also have to do a little work in making sure that the code is presentable, cleaned up, etc, so we can't release everything all at once, right now.

    We also do not want to overload the installer by adding in a whole bunch of unit test code that not every one would want, so I would expect our unit tests to be a separate download.

    So, stay tuned. You should be seeing some new downloads pretty soon, and we'll be trickling out the tests for individual product throughout the next year.

  • More evil laughter and even less information



    (I think this is the screenshot many people have been waiting for!)

    Remember: booth 131 at DevConnections Monday, Tuesday and Wednesday next week...


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