This Blog


Favorite Posts


June 2009 - Posts

  • Sneak peek: Not only 2D funnel charts but 3D ones too

    One of a series of posts on the new functionality that'll appear in DXperience v2009 vol 2. This is all pre-beta stuff. The beta will be released to DXperience Enterprise and Universal customers at the beginning of July.

    Ha! Didn't take long. Our chart guys decided to make the funnel chart described here into a 3D one as well:

    3D Funnel chart

    Love the rendering of an "interior" to the funnel.

  • Sneak peek: Scale breaks in WinForms and web charts

    One of a series of posts on the new functionality that'll appear in DXperience v2009 vol 2. This is all pre-beta stuff. The beta will be released to DXperience Enterprise and Universal customers at the beginning of July.

    This particular new feature has been requested for a while and is essential for bar charts or line charts where the point coordinates for the Y-axis vary widely (or maybe wildly).

    Scale breaks in XtraCharts

    Certainly you can use logarithmic scales to bring the coordinates into control or into view, but the interpretation of and relationships between the data points become a little more difficult. Scale breaks divide up the axis in to disjoint "bands", so that you can still get some understanding of how the data differs. Note that there can still be some difficulty, but it's a different quality than from trying to interpret logs.

    Of course, using neither logs or scale breaks means that the "large" data overpowers the "small" data, which could be, in itself, difficult to interpret (imagine the above chart as a normal bar chart: the bar for Jupiter would be 30 times the height of that of the inner four planets, dominating the chart, and it would be then hard to understand the relationship between the inner four's data).

  • From the DevExpress Labs: Early preview of ASP.NET MVC grid

    We can't help it. We love grids. We love new technology. So the opportunity to marry them together is irresistible. Here's a very early preview of what could become a new product, although I emphasize there is a very long way to go. So don't ask about release dates or betas just yet, just enjoy.

    We were slightly dissatisfied with the "force your ASP.NET controls to work in ASP.NET MVC" solution and wondered if there was a way to write a "native" control for ASP.NET MVC. You know the patter by now: MVC gives you full control over your HTML and CSS, etc, and ASP.NET controls tend to be "heavy" in that kind of environment. So, a team went off and did some experiments and wrote some code.

    Here's a screenshot of the resulting control:


    First off, it's read-only; no editing of data yet. But, nevertheless, it's fully interactive: click on the column headers to sort by those headers, drag a header to rearrange the columns:


    As you can see by the navigation links bottom right, the grid is paged.

    And the pièce de résistance: a snapshot of the HTML behind it:


    Is that clean or what? Some nifty REST links, and it's all ready for that extra touch of custom CSS.

    At present there's quite a bit of code that needs to be written to get this up-and-running, and, as this is likely to change, I won't go into any details here. But, note that MVC, in comparison to the traditional ASP.NET, will always require you to write some code. It's that whole "getting full control" thing again.

    But, despite all that, a brilliant bit of work from our ASP.NET MVC team. Thanks, guys.

  • VCL 2009 roadmap

    Despite the replies I've posted in forum posts over the past few months about our VCL roadmap, they're proving hard to find. Indeed, I couldn't find my previous answers myself and I wrote them. Sigh. Someone needs to teach me how to add searchable keywords...

    Anyway, a quick recap of the 2009 roadmap for VCL customers is in order:

    • ExpressQuantumTreeList v5 is almost done.
    • ExpressLayout Control v2
      • First beta will be released in Build 44
      • List of features will be published with Build 44 (I'll publish them in a blog post then)
      • Aiming for an August release
    • ExpressPrinting System v4
      • Beta in August
      • Release in September/October
      • Features include:
        • PDF support
        • Separate the ReportLink packages into design and runtime parts
        • Skinnable dialogs to bring visual consistency in skinned applications
        • Add the capability to display the Print Preview dialog using the Ribbon style (to bring visual consistency in Ribbon style applications)
        • Add the capability to print TcxLabel controls
    • ExpressQuantumGrid v7
      • Beta in Q4 perhaps.
      • Release late in the year, maybe next year
      • No official details on features yet
  • SD Times 100 Award

    SD Times has just announced the winners for their 2009 SD Times 100 awards, the 100 companies that have influenced and innovated the most in our industry. Actually that's not quite right: although they've just published the list on their website, last week they "leaked" the awards ahead of time by tweeting them on Twitter.

    SD Times 2009 award For the third year in a row, DevExpress was given one of the awards in the Components and Libraries section. W00t! I must say it's always good to be recognized as one of the "companies that have stayed on top of the latest platforms and protocols". It's a tough job, but someone's got to do it.

    Thanks Alan and David and all of the other editors for the recognition!

  • Graph databases

    There's a new database concept in town devised especially to store a traditional computer science data structure: a graph or a network. This type of database is called a graph database or, sometimes, a key/value database. They've come to the fore recently because of an extremely good open source implementation in Java called Neo4j, released a couple of months ago. There's none that I can find for .NET yet, although I suppose some enterprising C# dev may be converting Neo4j à la NHibernate.

    If you've done much database work, you'll know that although relational databases work extremely well for what we may describe as traditional data, data for which we know the attributes ahead of time and that naturally falls into what you might call a tabular form, rows and columns. Customers, orders, order lines and so on so forth. (I know, I know, a gross over-generalization.) In essence because the data has such structure (or because we've been able to impose such a structure on it) modern RDBMSs have optimized the heck out of themselves and out of SQL. We achieved simplicity of abstraction, robustness of implementation, great performance with these database servers, however there's still one area where the story is not quite so simple: scalability (we tend to throw faster hardware at our database server, not necessarily more servers).

    Although RDBMSs have given us a lot of benefits and a great abstraction for many years, they've become a jack-of-all-trades type solution rather than being the best at everything. The example I've given so far is scalability: with an RDBMS we add more disks, replace the processor with a faster one, and so on, when the access load starts to bite. Because of the inherent complexity of the whole RDBMS it's really hard to add another server. There's whole decisions about partitioning the database in the most efficient manner and other types of problems. If you are running a large web site or are running many heavily-loaded web services, a single database server will be your bottleneck.

    Another problem with relational database systems is the "baking in" of initial design decisions. How many times have you run into the issue of "oops, we forgot this attribute for this data type" and then have to rebuild your schema to accommodate it? Easy enough during development of the first version, but ruddy hard in version 3.0 when the schema is "bedded down" and you are really loath to change it. I'm sure we've all done the "add this special code to the Description field to store this attribute" hack. 

    Yet another problem is the fact that, in order to try and mitigate the above issue perhaps, you add many columns to your records and end up with a sparse table, where not every record stores the same data and so columns have little data in them, maybe just values for a few records only.

    Finally -- and I'm not trying to nail down the coffin lid here, just pointing out issues with the relational model -- we have what might be called the social media issue or the six degrees of separation problem. More and more of our data forms a network or a graph. In computer science a graph is a set of nodes and edges, the latter being the links between the nodes. A simple binary tree is a graph, a very simple one where the edges only go between a parent and its children. Imagine a graph that describes the interstate system in the US: we have cities as nodes, and then the edges are the various highways. We can attach attributes to the nodes and we can attach attributes to the interstates. Sometimes those attributes will be the same for all nodes (for example, population, area) and for all edges (distance), but there may be other attributes that do not apply to all cities (name of main island would apply to New York, but not Denver). Another example of such a model is Twitter, where the nodes are people on the service and the edges are defined by the "follows" relation. (In fact, here the edge is directed, the link has a direction, an arrow. I may be following you, but it doesn't mean you are following me back.) Persisting this kind of network model is not geared to a relational database, especially when you want to ask questions like "Am I following someone who is following Joe Blow?".

    Whether a node or an edge, you are modeling key/value pairs. Each entity in your model has a key (so you can find it again) and a value (which can be a whole list of properties, themselves key/value pairs). 

    The various cloud implementations have been pointing the way for a while: if you store database-type data in the cloud, you basically give up a wonderful traditional (academic?) normalized relational schema and go for something more on the wild side. individual tables that you load with data and query the heck out of (Azure uses LINQ, for example). No relations between tables (unless you code that in, in some fashion). Amazon's SimpleDB works in the same fashion: you create a data set, insert a bunch of data (the "records" do not have to have the same attributes or structure), and then query the heck out of it. In both these cloud examples, you do not have to predefine your data structure or worry about indexes or keys; in essence, the items you insert have associated properties that are defined when the item is added and the cloud engine takes care of everything else (including, hurrah, spreading your data across several servers both for scalability and for redundancy). Sometimes, even, the data you store has to be string values only; sometimes you get access to other primitives like ints, booleans, and lists.

    A graph database, then, is a special persistence engine for storing key/value data. If you like, it's a persistent hash table or dictionary (shameless plug: I described a persistent hash table in my 2001 book Tomes of Delphi, Algorithms and Data Structures). Because of its association with cloud computing, its API tends to be REST-based (it's a web service after all).  It has a query system that allows you to easily query the data, but it's nowhere near as powerful as SQL. It doesn't require a fixed schema, which can be good in some ways (you can extend the attributes you store easily), but bad in others (optimizing a schema for efficient access is impossible without one). It maps very easily to an object-relational model in your code, in particular there's no need for any kind of object-relational mapping framework.

    All is not sunshine and roses, however. In throwing away the RDBMS, you're also throwing away things like data integrity and data robustness, especially integrity enforced by the database schema. As I noted above, by planning a schema, you have a better chance of being able to optimize it (setting up indexes, and so on, based on the application's needs) rather than rely on the graph engine's own auto-optimization code. Also there's no standardization between graph databases yet, unlike, say, SQL.

    Despite all that, Neo4j and the various cloud computing services are pointing the way to graph databases becoming more prevalent in certain situations. Things are starting to look very interesting on the persistence front.

    (Some extra reading:


  • DevExpress Newsletter 4: Message from the CTO

    Here's the Message from the CTO from the fourth DevExpress Newsletter:

    We're developers, right? We are gods in the machine, our world is black and white, binary ones and zeros are our meat and drink. As such, we see through marketing blurb in a trice. Us click on AdSense links or read ads in MSDN Magazine? Never! Ergo, it's not worth spending money on, right?

    Actually it is. Any company that wants to grow (by definition, that's all of them) has to spend time, resources, and money on getting the word out to entice new customers to purchase. There's always attrition, so you must find new customers. There's cold calling (yuk) or there's advertising and marketing. The alternative — sitting back and hoping you get noticed or talked about — is way riskier.

    We, of course, want to bring you (and excite you with) new products and functionality, and to do that we have to get new customers. To do that, we advertise, we purchase AdSense, we go to big events like TechEd and support local user groups when we can, we fiddle with SEO strategies, we produce this newsletter. In short, we try to get our brand noticed.

    Marketing, no matter what we may think of it personally, is vital for a company's survival.

    Provocative? I know many customers disparage our marketing in the sense that they believe we should be plowing back that money into R&D instead ("the products will sell themselves" usually with a following clause, "if only you had X, so mobilize the team and start writing it"). Also, marketing is not just magazine ads or web banners or conferences or sponsorship. It's also our evangelism efforts, for another example (blogging, twittering, answering phones and talking to customers, and so on). So, what do you think?

  • Sneak peek: Automatic date-time scales for charts (WinForms and ASP.NET)

    One of a series of posts on the new functionality that'll appear in DXperience v2009 vol 2. This is all pre-beta stuff, it'll probably be something like the end of the month before the beta is ready.

    This new feature is cool (not that the others weren't of course). It lets the chart decide how best to display a date-time scale based in the input series data and automatically specify the DateTimeMeasurementUnit and DateTimeGridAlignment properties to give the optimal display for the space constraints of the chart. Give the chart more room and the date-time scale will automatically change to a finer resolution of the data.

    Pictures are worth more than words. Here's a bar chart showing some data by year.

    Chart by year

    If I resize the window to give the chart more room, suddenly it'll decide that it can display the data by month instead.

    Chart by month

    This feature means that you don't have to decide a priori which date-time scale to use, or to provide an option for the end-user to switch scales. XtraCharts will do the heavy lifting.

  • Sneak peek EXTRA: Hit testing in ASP.NET charts too

    I feel like one of those newspaper boys on the streets in those old black-and-white newsreels: "Extra, extra, read all about it!"

    Damon, the team lead on the XtraCharts team, informs me that the new hit-testing support works on web charts too. So, if you are using the ASP.NET side of XtraCharts, you will have hit-test events triggered on the diagram, the panes, the series, the data points, the axes, the titles, the labels, the legends, and so on.


  • Sneak peek: Custom draw axis labels in XtraCharts v2009 vol 2 (WinForms and ASP.NET charting)

    One of a series of posts on the new functionality that'll appear in DXperience v2009 vol 2. This is all pre-beta stuff, it'll probably be something like the end of the month before the beta is ready.

    In this post, a quick look at the feature that allows you to custom draw the axis labels for your chart so, instead of accepting the default text that XtraCharts provides, you can jazz it up to suit the data or the chart you are displaying. For example, in this screenshot from the demo, the Y axis axis labels are drawn to size to indicate the values, and also negative labels are shown in red and positive ones in green.

    Custom draw axis labels


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, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. 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-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners