This Blog


Favorite Posts


January 2007 - Posts

  • New XtraReports screencasts

    Our documentation people have just uploaded four more screencasts for your instruction and viewing pleasure. I hesitate to say auditory pleasure, since I'm narrating, but they're certainly interesting and informative.

    This latest set is all about XtraReports and introduces some simple scenarios using that product in both WinForms and ASP.NET applications.

    The first guides you through how to create a simple report WinForms application in Visual Studio 2005. You'll learn how to add an empty report to your application, add static text to a report, preview and print it, and even how to run its end-user designer.

    The second creates a WinForms application containing a data-aware report, again using Visual Studio 2005. You will learn how to bind a report to data using .NET data providers, edit report bands, use the Field List window to add bound report controls to the report, and number the pages in a report.

    The third introduces the creation of a master-detail report at design time using Detail Report Bands. This is a very convenient way of creating reports that are bound to data containing an ADO.NET relationship because it allows both the master and detail reports to be created in the same XtraReport object. Again, this is a WinForms application.

    The fourth and final lesson will guide you through the process of creating an ASP.NET application that contains a data-aware report. It describes how to use the ReportViewer and ReportToolbar controls to embed a report into a Web page, and also how to customize some options that affect the Web report application.


  • Calling Occupants of Interplanetary Craft

    A customer emailed me yesterday using my personal email address rather than my Developer Express one. He apologized for doing so, and said in his email that my "DevExpress address seemed to be unavailable." I got all worried thinking that our email server was bouncing messages, but what he meant was he couldn't find my Developer Express email address.

    True, it's not easily findable on our main web site (well, that's probably because it's not there!), but I do use it on our newsgroups for example without obfuscating it. I'm really not trying to hide behind a wall of bits and electrons, so I think it's time for me to post my contact details again.

    If you have something to say about Developer Express on the technical or technology side (I am after all Chief Technology Officer), that is, something to say about the products, the documentation, the support, the install — be it good or bad — you can reach me in two ways.

    Email: julianb@devexpress.com
    Direct line: +1 818 844 3383 ext. 206

    I would ask though, if you do want to phone me, to please limit the hours between 9am and 5pm Mountain Time (GMT-7), Monday to Friday. You may find I'll answer outside those times, but I can't guarantee it (yes, I do have a home life too!).

    A couple of points though:

    First, I'm not a support engineer. Really, I kid you not. If you want to know how to do foobar with our wotsit component, I'm just not the person to ask; that's what our support team are for. They work day in day out with our components and know far more, far better than I. I'd come across as a complete bumbling buffoon. But if you want to say "So-and-so was brilliant at solving my problem, he ought to get the employee of the month award" or "The developers have flagged my issue as Won't Fix" then by all means contact me and let's talk about it.

    Second, I can't help you in any meaningful fashion with client services type things. I really can't: I'm just not connected to their systems in any form. Likewise, I don't have any handy coupon codes, I'm not authorized to give you an extra 50% off, and I can't explain why something's disappeared from your Client Center. So you should continue to use clientservices@devexpress.com or our main phone number +1 702 262 0609 for those kinds of things. About the only thing I can do is to make sure that Client Services got your email, if you sent one and it all went quiet.

  • Julian is on The Delphi Hour Wednesday 31-Jan, 17:00PST

    Just a quick head's up: I'm the guest this week on The Delphi Hour with Nick Hodges. You can access it here http://dn.codegear.com/article/33592 at 17:00 PST on Wednesday 31-Jan-2007.

    It's live -- shock, horror -- and there will be no opportunitity for me to dodge the hard questions, edit what I sound like, or the bloopers I make. I understand from Nick that it's archived so you can listen to it as a podcast later.

    Aside: when I told my wife about this, she said, oh it's Geek Radio, then. By geeks, for geeks, and it's only on the Internet. I said, yep, that's about right.

    Anyway, if you're into Delphi and our VCL products, do please listen in. It should be a hoot!

    (Update: it was a hoot. I enjoyed myself hugely. You can hear the archived podcast here: http://dn.codegear.com/article/34029)


  • Can't Fix? Won't Fix!

    This morning I was writing to a customer to explain the "By Design" and "Won't Fix" resolutions we can apply to an issue, and I thought it would be beneficial to publish my reply to a wider audience.

    When we design and implement a component, we start from a position of how we think it will be used and what its features should be to support that usage. If you like, we embed our own assumptions and biases into the component. Later on, when a customer uses the component in a different way and has problems, we're in a bind. Sometimes we're lucky: we can find a workaround that keeps the customer moving, or we can see a "simple" bug-fix that gets around the issue.

    Sometimes we're not so lucky. We find that an assumption we made early on is wrong but unfortunately that assumption is baked into the design. This is a real hard one: we fully appreciate the problem and slap each other upside the head, but it's not going to be a simple bug-fix to make. We have to tear apart the component in some fashion, redesign some portion of it to avoid the problem, and somehow bring it all back together so that we preserve backwards compatibility. Good luck with that, someone's got to do it, when the going gets tough the tough get going, etc.

    It's at this point where it seems we're punting the issue. We'll perhaps mark it as By Design, meaning that, yes, we see the problem, but we think the usage goes beyond what we think the component was designed for. In general, we'll also put it to one side and think about implementing a different component or a more flexible version of it in the future, where we can plan for informing customers that there will be breaking changes, for instance.

    Perhaps we'll mark it as Won't Fix instead. This is a more contentious resolution, most obviously because of the phrase. (Images of the development team with folded arms, stamping their feet, screaming No Way!, come to mind.) There are two main reasons here, I suppose. The first is an extension of the By Design resolution: the component is so set in concrete that the only way to fix the issue is to redesign and rewrite the whole thing. In other words, we simply cannot fix the issue, we just have to throw the whole thing away and start over. The second is to simply say that to fix it would require us to develop some software that is not part of our main goals, in essence that goes beyond what we want to do as a company.

    A couple of examples might make this clear. Our WinForms scheduler component has some issues when it comes to emulating the Office 2007 look-and-feel (which is why you haven't seen anything along those lines yet). We decided early on in the Office 2007 betas that the current design just wasn't flexible enough to emulate some of the new features of Outlook 2007. This is an obvious case of marking an issue as "By Design" or even "Won't Fix" and moving on, but we realized that such a decision doesn't match our company goals and so we're rewriting the component (there's another reason as well: we're redesigning it so that we can reuse code for a future ASP.NET scheduler). But, and this is going to be a big problem, it's likely that there will be breaking changes when the Scheduler Mark II becomes available.

    Another: our eXpress Application Framework (XAF) enables you to write business applications very quickly. Our goals for this product are being met (it's still in beta), but we're getting some pushback with regard to the multi-tier aspects of the applications we create. We've shown how to use .NET Remoting and WCF (and I think even RemObjects' remoting product), but we've steadfastly refused to produce our own. Such a remoting product is just not aligned with our company goals (at least, not at the moment, but who knows?) and so it becomes a Won't Fix.

    Now, having said all that, sometimes an issue will be marked as By Design or Won't Fix just because the developer is having a bad day and can't be bothered. We do try and avoid this situation because of course it's just not acceptable. So if you feel that the resolution you've received is just avoiding the issue, let me know and I'll dig into it. I don't guarantee I'll change the resolution, but at least I'll check.


  • DevWeek 2007 (aka, the Brit visits home)

    There's this great conference in London at the end of February that modestly bills itself as "The UK's Biggest Conference for Developers, DBAs and IT Architects" and Developer Express are going to be there in force. It's DevWeek 2007, it's from February 26 to March 2, it's in trendy Islington at the Business Design Centre, and it's an opportunity for you to meet Mark Miller and me. If you live in the UK, what more could you want from a conference?

    Mark will be presenting a session on "Best practices with the .NET Event/Delegate Framework", I'll be trying to hide my American inflexion on certain words as I speak, and we'll both be at the DevExpress booth in the Exhibit Hall.

    If you know any great pubs in the area, you must drop by and let us know and we'll stand a round. Even if you don't know of any, stop by anyway, we'd still like to meet you!

  • Internal discussions

    Over the past weekend, we had our annual Developer Express "what the [bleep] are we doing?" getogether, spread out over four days.

    In essence, the movers and shakers in the company got locked into a room and discussed what we did in 2006, what went right, what went wrong (yes, I have to report there was some, some of it not visible outside the company), and what we'll do in 2007 to keep on doing what we did right and to stop doing what we did wrong. Oh, and also what we're planning to release in 2007.

    I, for some inexplicable reason, managed to contract the flu and it made itself felt on the second day. So I've probably infected the upper echelons of the company and you may see us dropping like flies over the next couple of days.

    Anyway, despite this incident of British viral warfare, we had some extremely productive discussions. A lot of it I can't talk about, for obvious reasons, but there were some conclusions we came to that I can outline here and flesh out in detail over the next few weeks and months.

    1. We have to enhance our contact with our customers. No, not by spamming you with emails (ha!), but by some new initiatives. First up, I'm looking into the possibility of having regular chat sessions (an hour long, say, biweekly and varying the time to suit customers around the world) where we meet with our customers electronically by using some kind of moderated chat software. We would specify the topic of discussion of each chat up front, say on our main web page, and I would invite people from the company who would be able to help answer questions on that topic. So, for example, we could discuss future products or features, design issues with this component, extensibility points for that component, or development problems with this other component. You get the idea. My first job is to find some chat software (if you have any thoughts, please let me know).

    2. We've got to do a better job at letting you know where we're going to be, with respect to conferences or user group meetings. I know, you're shaking your head, duh, this is really obvious. Yep, it is, but sometimes you have to be hit over the head to see how apparent it is. Anyway, we've already set up an internal tracking system for this need, and I see that Mehul has kicked off the first post on the topic. (The second one is here.)

    3. We have to help you find the information you need to succeed with our components. We have a huge knowledgebase (KB) of information, but, to be honest, searching it is a pain. So we have a project to implement a new search engine for the knowledgebase (details still being decided) and also we're seeing how we can incorporate KB information into our help files so it's available to you at design-time. This would have a double benefit: first, you will be able to more easily find the information we have that you need, and, second, by being successful at that we help reduce some of our support burden (which has increased noticeably in the last six months). This is, needless to say, a more long-term project than some of the others.

    4. We must get better at releases. This covers a multitude of sins, but, in essence, we must make you aware of what's coming up earlier than we have done, be ready with the release content (press release, what's new, web site update, etc). You only have to look at our recent release of CodeRush and Refactor! Pro 2.1 to see what I mean: a great release, but we didn't have all the ancillary content ready at the same time. Which is surprising, sigh, considering we had enough time to get it ready. Talking of CodeRush and Refactor! Pro, Mark and the IDE team have agreed to sync their releases to the main DXperience releases.

    That's about all for now; stay tuned for more information as we blog about it.

  • Two point one...

    There's a breathless hush in the auditorium. The audience look around expectantly, peering in to the shadows, trying to be the first to spot the announcer. A small disturbance over on the right results in a communal intake of breath that seems to wash over the room spreading like a whispering wave. The spotlight snaps on highlighting the stage, and...

    Ladies and gentlemen, CodeRush and Refactor! Pro 2.1 are released.

    Yes, after some very hairy last-minute problems with the installer and a couple of performance issues (all nailed by the team), we are proud to announce versions 2.1 of DXCore, Refactor! Pro, and CodeRush. I admit it's been a while since we released 2.0.4, but the wait is worth it (and I promise we won't make you wait this long in the future). If you are existing customers, your Client Center should have been updated by the time you read this. We're still updating the content on our web site.

    So what's new? A veritable gaggle of features, that's what. I'll start off with the new refactorings in Refactor! Pro. They fall in two main areas: the usual code refactorings, and, wait for it, the new refactorings for ASP.NET. You heard that right: we are branching out into the ASP.NET space to give you all the goodness of Refactor! Pro for your .aspx pages. Let's begin with those:

    • Add Validator adds one or more selected Validators to the active input control (that is, the control containing the caret).
    • Extract ContentPlaceHolder moves the selected content from a .master page to a new .aspx file, placing it inside asp:content tags, and inserts a new asp:contentplaceholder tag at the extraction point inside the master page.
    • Extract ContentPlaceHolder (and create master page) moves the content that is outside of the selection in the active .aspx page to a new master page, inserting a asp:contentplaceholder tag to reference the extracted content, and then wraps the selection in the aspx page with asp:content tags and adds a MasterPageFile attribute to link to the new master page. This refactoring is essential for when you migrate your older ASP.NET 1.1 applications to the newer ASP.NET 2.0 and you want to take advantage of the new master pages.
    • Extract Style (class) converts an inline style to a named class style. This and the next one are great for building up a set of CSS styles that you can reuse in your .aspx pages
    • Extract Style (id) converts an inline style to a named id style.
    • Move Style Attributes to CSS moves styling attributes from the active control to a new CSS class and applies the class to the control. Another one of those great "make things reusable" refactorings.
    • Move to Code-behind moves code located in script tags to the code-behind file. For those occasions where you inherit some .aspx pages written by someone else who didn't understand about code-behind and want to apply further code refactorings to the result.
    • Rename renames the active local variable, function, method, field, property, parameter, type, namespace, CSS style and updates all references to the modified element.
    • Surround with Update Panel surrounds a contiguous block of text in the source view with atlas:UpdatePanel... and ContentTemplate tags.

    In the area of code refactorings, we of course have some more new refactorings, of which some are still marked as "early experience" (which means we haven't completed testing them in all scenarios although they work well in all common situations). You can elect to turn off the early experience refactorings if you want through the Editor\Refactoring\Early Experience options page.

    • Add Parameter adds a new parameter to a method's declaration and updates all calling sites accordingly.
    • Boolean to Enum converts a Boolean type to an enumeration, updating client code if necessary. This is for those occasions where you have an existing method returning a Boolean, but suddenly realize that there is another result you want to return (for fans of The Daily WTF, this means you can now convert a Boolean result into an enumeration with True, False, and FileNotFound).
    • Break Apart Parameters places each parameter on a separate line, making code easier to read in certain situations.
    • Create Method Stub generates a method for the selected call, with appropriate parameters and return result. This is a great timesaver for the TDD crowd, of which I am one.
    • Extract Function (outside of class) moves selected code into a new function within the enclosing namespace [C++ only].
    • Introduce Parameter Object consolidates selected parameters into single object [Early Experience]. This is handy if you have a method with lots of parameters and you want to clean up its declaration.
    • Move Method to Header moves a method from a source file into the class declaration (in the header file) [C++ only].
    • Move Method to Source File moves a method's implementation to a source file and creates a declaration in the header file [C++ only].
    • Promote to Parameter removes all references to the field or a local declaration from the method, replacing it with a parameter. Calling code is adjusted to now pass in the field or expression of the local declaration as the argument for the new parameter [Early Experience]. An adjunct to the Add Parameter refactoring, and, at least for the way I program, possibly more useful.
    • Remove Parameter removes an unused parameter from a method declaration and updates all calls accordingly.
    • Rename renames the global variable (C++), or macro (C++) and updates all references to the modified element.
    • Replace with Alias replaces the type at the caret position with an existing type alias.
    • Split With Statement splits a With statement into two, one nested inside the other [VB only].

    Note that we have added a new multi-file undo manager to Refactor! Pro, even in Visual Studio 2002 and 2003 (which don't have such a thing), so that the renaming of public identifiers not only works but you can undo it too (this was an early experience feature in 2.0.4).

    I would also add that we have fixed numerous minor bugs to do with refactoring generics in C# 2.0.

    And now CodeRush 2.1. What's new there? Well, the biggest feature for me is undoubtedly our new, fast support for navigating references. First, there's the new Tab to Next Identifier feature: place your caret in an identifier and press Tab and CodeRush takes you to the next instance of that identifier in your code (Shift+Tab goes to the previous one). It's that simple and, once you've used it, you'll never be able to do without it.

    Second, as if that feature wasn't enough, we have the new References Tool Window. This is an extremely fast reference-finding tool (2-10 times faster than our closest competitors), and it’s the only reference-finding tool with a Live Sync option to show all references all the time. As you navigate through your code, this tool window stays updated showing the references for the identifier under the caret, or if you find that distracting (say, your caret moves into "int") you can turn off the Live Sync feature and use a keyboard shortcut to update it for the identifier under the caret.

    You can watch a screencast of the new references features here.

    There's some new templates as well as some changes to the templating engine:

    • "evar" creates events with Add and Remove accessors.
    • dr." creates "DialogResult.
    • "c," creates classes that don't have constructors (the "," at the end of a template, by convention, means that it will have a shorter expansion than the same template without the comma).
    • "c?Type?" creates classes that descend from types with template mnemonics. This is most useful if you've right-clicked on types you regularly work and selected the "Use Type in Templates…" menu item. For example, if you had a class called "Employee", and you assigned a mnemonic of "e" to that type, you can declare a descendant of employee by expanding "ce".
    • Static/shared members can now be declared by making the first letter of the template uppercase. For example, "Mb" will create a static/shared function that returns a Boolean.
    • Parameter templates now add commas if they are missing.
    • Member and type declaration templates now use the default scope settings from the new Editor\Code Style\Scope options page.

    And then there's Mark's favorite new feature (apart from the references features): Step Into Member. This cool new debugging feature allows you to step inside the member at the caret (without stepping into any other members that might also be on the same line).

    There's a bunch of new stuff for DXCore as well, but since that's not used by the majority of our customers, I'll leave it for another post.

    Update: for some reason, cutting and pasting into Community Server screwed up some tag names. Corrected.

  • Our customers are the best

    We have the best customers. No, really, I kid you not.

    Although I won't go over it again in detail, we made a mistake in the gap between Christmas and the New Year. In the grand scheme of things it was a minor error, but, nevertheless, I emailed everyone concerned with our apologies.

    I got back some (that's "some" as in several hundred) pretty amazing and hilarious replies, some of which I'd like to share with you (slightly edited, with my comments in square brackets). I'll be anonymous though to protect the guilty. Our customers were certainly enjoying the holiday season, both as evinced by these replies as well as by all the "out of the office" messages I got.

    • Errare humanum est. [Phew, Latin, no less! From Seneca the Younger, according to wikipedia.]
    • You screwed up so badly that I want a full refund!!! And a pony! And a plastic rocket ship.
    • In Russian we have a saying: Only if you do nothing will you not make mistakes.
    • There are many, many other and much more important things in life to get worried about. What about our soccer competition being boring from the first day it started? Me missing a century by a thin hair during snooker the other day?
    • You guys rock, and glad to see you have problems like the rest of us who live on planet Earth! (You should stop selling to the Martians.. they're pretentious and short tempered..)
    • You have an update available?
    • It's OK. Your automated system was weary of inactivity.
    • No worries. I once had a similar experience where an application I wrote went bonkers and sent 19,000 emails to the same fellow (my boss :-D ) in one night!
    • I have been severely traumatized by the daunting task of pressing the black "X" icon in Outlook 8 more times than I was expecting to today.
    • No problem Jim. [Uh...]
    • I appreciate your apology, it just shows once again what a first class organization you have. Keep up the great work. Your tools have taken our software to another level. [Sorry for repeating the obvious marketing quote: I was just trying it out for size .]
    • EIGHT? I'VE BEEN CHEATED! I only got five!
    • Thanks for coming out and admitting the mistake up front. Took a lot of guts to through yourself under the bus like that, and with a cell phone to boot. [Yep, I'm writing this from the hospital bed.]
    • Keep up the great work. If I could just take this opportunity to request CF support? [Heh, the old one-two: first the buttering-up and then the entreaty...]
    • As I have never made a mistake in my life (well, to be honest I did think OS/2 was the future of computers a few years back) I think this transgression of my inbox is unforgivable! [Heh, heh, he said OS/2.]
    • Just get the next release of CodeRush out and I'll forgive you. [Yo, Mark, this one's for you!]
    • I only got it seven times. Does that make me one of your preferred customers? [Ouch]
    • Because you used the word vociferously in an E-Mail, I accept your apology!
    • Everybody screws up now and again. It would be nice if I could manage to screw up as little as you guys do.
    • Bloody hell mate, it's bloody Christmas, life's too short to get your knickers in a twist about little things like this. [Yep, you guessed it: from a customer in Australia... It helps if you say it out loud pretending to be Crocodile Dundee.]
    • I regard sending out some unnecessary notifications a very minor mistake. If I were to prioritize my expectations to a component vendor, "No unnecessary notifications" would be number 51 on the list. And you fare very well on the 50 before that.
    • Once in a while my program has bugs too.
    • I'll let you off this time... but if you start marketing Viagra, *** enhancements, stock tips or abdominal exercisers you're in serious trouble! {Rats, strike those off the list for 2007.]
    • To err is human, to really screw things up you need a computer. {Since several people sent this, I imagine it must be an "official" quote so I looked it up. It's generally known as Turnauckas' Observation. There's also a Turnauckas' Law: "The attention span of a computer is only as long as its electrical cord."]
    • Thank you for letting me know that I did not have 8 records in your database. [Subtle!]
    • You've saved me months of implementation time, what's 10 seconds with the delete key?
    • I'm especially looking forward to the next version of ExpressBars, so please feel free to email me 10-20 times when it's available! [Bwhahahaha!]
    • We did this once - our newsletter server started looping. And when we sent our apology email, that started looping too!! [Now, that was a brave move, I'm afraid I insisted on my apology email being sent by another program altogether.]
    • I just thought: strange that this happens to DevExpress, they always seem so well-organized. [Little do you know, everyone, little do you know... We're like a swan gliding over the water, on top it's all serene, but underneath it's paddling like crazy.]
    • You surely understand that the honest people on your recipient list have all committed the same mistake as you. {Let's take a count: put up your hands everyone who's done something similar. Er, OK, let's do it the other way, put up your hands if you haven't...]
    • Hey, I remember you from the TurboPower days. I was a big user of B-Tree Filer. {There is literally no escape...]
    • I would like to complain that I did not receive my eight copies of your latest missive as detailed below. I see no reason why I should be singled out amongst your many customers as being unworthy of said notification. I know this is the season of goodwill and that I should be more accommodating to my fellow users. However, this is also the season of receiving and, quite frankly, I didn't. Please forward my eight release notifications as soon as possible.
    • No worries, I just assumed you were VERY keen to get the news about the updates out.
    • My goodness, stuff happens. It's the holiday season. My message to the complainers is relax and drink some eggnog! [(From someone in the Netherlands) My paternal grandmother was always fond of a little advocaat at Christmas, but I'm afraid that gene didn't make it to me. Yech.]

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