This Blog


Favorite Posts


February 2009 - Posts

  • End-user documentation for .NET products now available

    Just a quick note to say that the end-user documentation I promised here a couple of weeks ago is now available for download. You can either download help files for individual controls, or download the entire pack. If there are any issues with the content, please don't hesitate to contact our support team and let them know.

    Download Documentation for .NET Products.

  • Previewing v2009 vol 1: Demo Center

    We're going to be talking about what's coming up in v2009 vol 1 over the next few days (hint: that means the beta is almost ready Smile), but I thought I'd throw in a quick screenshot of the new, refreshed Demo Center. If you've used our products for a while or you're new to DevExpress, Demo Center is run immediately after installing DXperience, so you're probably used to seeing the old version. It's a great way to explore what's new and the various features of our products.

    Here's the new DemoCenter:


    Note the new links to our training videos and our online documentation to help you get up to speed really quickly.

    Neat, eh?

    Right, he says, rolling up his sleeves, now to do some posts about what's new.

  • Previewing v2009 vol 1: Printing appointments from the WinForms scheduler

    We locked the scheduler team and the reporting team in the same broom closet for a little while this release cycle to come up with a great reporting solution for all those WinForms applications that use the scheduler. And just before they keeled over from the lack of oxygen, they came up with an excellent addition to XtraScheduler that will allow you to produce professional diaries and PIM-style reports from your appointments. This new functionality is only available if you have both XtraScheduler and XtraReports (say, as part of DXperience Enterprise) since it makes use of features from both. Let's take a look.

    First of all, one of the teams' main goals was to maintain as much flexibility as possible. This wasn't to be a "print screen" type solution, but a solution that should be designed. Hence the need for XtraReports: the new XtraScheduler Suite in v2009 vol 1 has a new control that descends from the XtraReport class called XtraSchedulerReport. This has the normal banded report designer that you're used to from XtraReports, and there are a set of new report controls that you can drop onto the designer surface to build up a scheduler report.

    The report gets its data through a print adapter. The main purpose of this adapter object is to compose a data set that will be used in the report. We provide two print adapters: the SchedulerStoragePrintAdapter and SchedulerControlPrintAdapter. Since the print adapters provide a set of validation events, you can easily filter the scheduler data to suit the report. As an example, you could handle the SchedulerPrintAdapter.ValidateAppointments event in order to print appointments which meet some specific criteria.

    The next layer is the report view. This is much like the view which exists in the XtraScheduler control, so there are ReportDayView, ReportWeekView, ReportTimelineView components.

    Finally, as stated above, the report itself is a container for report bands, and each band has a set of controls placed inside them. We provide two distinct sets of controls.
    The first, and most important set consists of controls that represent time cells with appointments. They are: DayViewTimeCells, HorizontalWeek, FullWeek, and TimelineCells. The second set of controls, the auxiliary controls if you like, include:

    • headers - the HorizontalResourceHeaders, VerticalResourceHeaders, HorizontalDateHeaders, DayOfWeekHeaders, and TimelineScaleHeaders.
    • calendar - the CalendarControl control
    • time ruler - the DayViewTimeRuler control
    • information - controls used to display miscellaneous information, such as the TimeIntervalInfo and ResourceInfo controls

    They are similar to the XtraReport controls you know now (in that they're only there to drop on the report designer surface, you can't use them elsewhere), although they have their own peculiarities.

    Since all that was a bit abstract, let's see how easy it is to create a professionally designed scheduler report.

    1. Open your XtraScheduler application.
    2. Choose Add New Item from the Project menu.
    3. Choose XtraScehduler Report Class. This will add a new blank scheduler report to your application.
    4. Visual Studio will display the report designer for the newly constructed instance (it's called XtraSchedulerReport1 by default). Open the Visual Studio Toolbox pane and open the DX: Scheduler Reporting tab. Drag and drop a DayViewTimeCells control onto the Detail Band of the report.
      You'll notice that an instance of the ReportDayView component is created automatically and placed in the component tray.
    5. Add a HorizontalResourceHeaders control. Place it above the DayViewTimeCells control, again in the Detail Band.
    6. Add a HorizontalDateHeaders control. Place it above the HorizontalResourceHeaders control, and resize it as needed. Its width will determine the width of the time cell area.
    7. Use the smart tag of the HorizontalResourceHeaders control to link it to the HorizontalDateHeaders control. Now the control is linked to the data provider (ReportDayView) and is anchored to the date headers.
    8. Use the smart tag of the DayViewTimeCells control to link it to the HorizontalResourceHeaders control.
    9. Add a DayViewTimeRuler control, and place it on the left side of the DayViewTimeCells control. Click its smart tag and link it to the DayViewTimeCells control. The time ruler is now also linked to the data provider (ReportDayView) and anchored to the time cells. Resize it if necessary for proper alignment.
    10. Add a TimeInfoControl and a CalendarControl to the Detail Band. Place them above all the other controls, at the top of the page. Use their smart tags to link them to the DayViewTimeCells control.

    The resulting designer view looks like this. You can easily identify the various controls used (each has a link icon).


    You can preview the report by clicking on the Preview tab in the designer. Within Visual Studio, some fake data is generated to populate the preview, however, if you invoke the end-user designer at run-time, the data you see will be "real".

    Use the following code to create the report at run time and bind it to the Scheduler control in your application:

    using DevExpress.XtraScheduler;
    using DevExpress.XtraScheduler.Reporting;
          XtraSchedulerReport1 xr = new XtraSchedulerReport1();
          SchedulerControlPrintAdapter scPrintAdapter = new SchedulerControlPrintAdapter(this.schedulerControl1);
          xr.SchedulerAdapter = scPrintAdapter;
          // The line below invokes the End-User Designer

    The preview looks like this:


    So, there you have it: creating a great-looking scheduler report in DXperience v2009 vol 1. Remember, although this is part of XtraScheduler, it does require XtraReports in order to function, so you must have licenses to both, or a license to a superset package containing them both, like DXperience Enterprise.

    Not too long to go before we release, so be ready to enjoy using this new functionality when we do.

  • Testing with Internet Explorer 8

    OK, this is both confusing and not confusing. For some reason, this morning was The Morning™ that I downloaded and installed IE8 RC1. Our ASP.NET evangelist Mehul Harry has been nagging me to do it for while (as in, "you are so far behind the cutting edge, Julian, you'll have to take into account the stretching of space-time in order to catch up"), so you could say I bowed to the inevitable.

    There was no problem in installing it, though it did want to reboot my machine (and configure a bunch of stuff during the reboot).

    Microscope with digital readoutOnce my machine was back, it was time to test. Because my own website is my home page (it saved all my configuration and bookmarks from IE7 — very nice), it was the first thing that came up and the first to fail. WTF, as they say on the internet.

    By "fail", I mean that the browser switched to "compatibility mode" in order to display the site. You could have heard me splutter up and down our hallway, here in the DevExpress offices. For, you see, I did at least know something about IE8: that it was extraordinarily standards-compliant and that at the drop of the proverbial hat it would switch to compatibility mode if it sniffed so much as a single problem with a web page (generally, that means compatibility with IE7, not with Firefox or something). In fact, my little website is not the only one: Mary-Jo Foley reports today that the list of IE8-incompatible sites (that IE8 uses to immediately display in compatibility-mode, no question) stands at 2,400 and counting. And they're sites like google.com, yahoo.com, and, ahem, microsoft.com, not sites like Joe the Biker's site about diners on Highway 42, which he maintains with a 10-year-old version of FrontPage.

    But the thing was, my site validates with XHTML 1.0 Transitional and also with CSS 2.1, using the W3C tools. Yes, that's "validates" as in "there are no errors". Perfectly legal HTML and CSS, which of course displays just fine with Firefox, Safari, and Chrome. And IE7. So, you'd have thought the page would display just fine in IE8 since, you know, it's "standards-compliant." Nope, a brief flicker and then the accusatory balloon comes up, wagging its metaphorical finger, saying that the page can only be shown in compatibility mode.

    At that point, I spent some time trying to find out why IE8 wouldn't display my website properly. Quite a bit of time. Let's put it like this: if you are in charge of a website and you want to make sure it displays properly in IE8 without it slipping into compatibility mode, you have a two-point plan. First, make sure the page's HTML and CSS validate. Second (optional), if it still doesn't display properly, pray to the old gods, preferably Thor and point him to Redmond. Or splutter. Or throw your mouse around. You see, the only, and I do mean only, help you get from Microsoft about making your sites IE8-compliant is to make sure they are valid HTML/CSS and have the right !DOCTYPE and so on. I searched quite a while.

    The wackiest thing: it still wouldn't display properly if I added the special meta tag that "tells" IE8 how to display the content (I used the "emulate IE7" option, but it didn't).

    In trying to find out what the issue was I did learn about IE8's Developer Tools. Go to Tools|Developer Tools or hit F12 (nice touch that: Firebug in Firefox uses F12 as the keystroke to open its panel/window), and you get a separate window displaying the various tools available to the web developer. There's a DOM explorer, a JavaScript debugger, a CSS explorer, and a profiler. You can set the main browser to display standard IE8 or in compatibility mode, and you can make changes to the HTML/CSS that are reflected immediately in the browser display. A very nice tool, indeed.

    Using it, I found that the issue was my main DIV having a float:left CSS style. Turn it off, and the site displayed perfectly; turn it on, I got a white screen. I think this is a bug in IE8 – I can't see why the main DIV can't be floating inside the BODY tag – but I've got to parse the W3C standards to see if I'm right or not and for that I need my copy of CSS: The Definitive Guide by Eric Meyer, which is at home.

    Interestingly enough, the home page on our web site contains the header's meta tag asking the browser to use IE7 mode, but the home page displays perfectly in IE8. I'll have to check to see why we did that, especially as we seem to have the meta tag twice (we want to make really sure).

    IE8 will soon be released (I think it's mid-March, probably around MIX09 time), so I would recommend that you spend a quick half-hour to see how your web site behaves with it. You may be lucky and there's nothing to do, or you may be unlucky and find that there's quite a bit. But it's much better knowing and you can always add the meta tag in the meantime.

  • Using DevExpress controls to get a great looking UI

    Mark Miller has been honing and refining his talk The Science of Great UI for a while now, and I've been privileged to see him in action presenting it several times. Every time he does it, he adds something new (or takes away something old) so it's always fresh, relevant, and up-to-date. Luckily for all of us, he's writing a series of blog posts here on what to look for in a well-designed screen so that we can all understand what's good or bad about a particular user interface or user experience.

    Adobe Photoshop Image SettingsHeck, even I'm learning the ability to "see" what's good or what's bad, and am applying it to my own website as well as critiquing the various visual aspects of DevExpress' controls, frameworks, and — next week — the new website.

    For fun — and also because, apart from a blog post a while back which showed off the feature with a set of "ransom demand" images, we haven't talked about our options for formatted text in our WinForms controls — I decided to mock up a configuration dialog that follows a couple of the principles that Mark talks about in his series: Clarity and Information Relevance. I'll use the formatted text feature to show this off.

    The config dialog I decided to use as a basis for my experiments was a panel from Adobe Photoshop that deals with Image Settings.

    First thing to do, is to decide on the colors. Since I want to be consistent in the color scheme (and don't have time to do a full skin), I decided on three colors (all RGB):

    • Background: 223, 223, 223 (a light gray, like the original)
    • Foreground: 80, 80, 80 (a dark gray, but now it's done, I think almost too dark)
    • Bolded foreground: 16, 16, 16 (almost black)

    Second, which font? I went for Calibri 10pt this time.

    Image Settings lookalike Then it was a case of dropping controls on the form, turning off the look-and-feel options (and setting the style to flat). Obviously, for a blog post like this, I don't have the time or resources to mimic the exact look of the original, especially with the track bars, but that's not what this is about.

    For the first check box, I set the Properties.AllowHtmlString option to true and then set Text to this:

    <color=0x101010><b>Zoom</b></color> and
    <color=0x101010><b>Crop</b></color> photos to fill grid cells.

    Notice that for the bolded words, I'm setting both the color (the bolded foreground from above), and also the bold attribute.

    The Text property for the other two check boxes looks like this, again explicitly setting the color and bold for the words with most relevance.

    <color=0x101010><b>Stroke</b></color> photo border
    Cast a <color=0x101010><b>Shadow</b></color> behind images.

    Note also the way the original designer not only bolded the relevant words, but also capitalized them for that extra bit of emphasis.

    Again, because of time constraints, I just used one of the built-in styles for the check box itself (Style4), rather than going for the Mac-looking check box of the original. Unfortunately, it's a little "heavy" for my taste.

    The rest of the dialog was just a case of dropping items on the form and setting the colors and font choices. Not having a dial control, I left out the final angle setting.

    I think there are two points to take away from this. The first one is about information relevance or clarity. Not everything in this config panel is equally important. The end-user, on being presented with this, is not really interested in the nice English text but is instead interested in the almost-black words and data. At a glance, we can see Zoom and Crop is off but Stroke and Shadow are on. We can see the values for opacity, offset, and radius immediately. The rest of the form just blends into the background (it's lower contrast), but is still very legible if we really need to read it.

    The second point is that we need to update some of our look-and-feel Smile.

  • The helmet idea for controlling your PC gains pace

    Back in October last year, at PDC 2008 in LA, we revealed to the world the secret work we'd been feverishly doing in our labs that resulted in the DXHelmet. To remind you about this technological breakthrough, you really should view the video again.


    We were obviously thinking more about our customers than the consumer world at large since we were so enchanted with making it work with Visual Studio to allow you to more easily write, manipulate, and refactor code that we didn't even consider that it could be used for something like, oh I don't know, but let's just say, gaming. For example.

    Well, it seems someone else took our ideas from the video and cleaned up the hardware a bit (well, we are better known for software) and now we're slapping ourselves upside the head for not thinking of the wider applicability of the underlying concept. We must have revealed more about the design in the video than we imagined.

    Take a look at this article from the Discovery Channel that talks about the concept, and then this video of a report on ABC News about it.


    Never let it be said that DevExpress is not on the cutting edge of technology. Heck, we were first! It's just we obviously think too much about writing great controls, frameworks, and tools for developers like you, than to coin it in the gaming market.

    Hmm. Er, Ray?

  • Using frameworks to enhance your applications

    Let's face it, writing any application these days, be it for a rich client or a thin one, starts off as if you're in a restaurant choosing from a menu. You're presented with a set of choices for this framework or that framework, some of which are de facto choices, others that may be less appealing. There are side dishes of controls you might want to use, so you have to select them as well.

    Frame of a house Because you're here reading this post on this particular website from this particular .NET control and framework vendor, we're going to assume that your number one, automatic choice will be the .NET Framework. A given, you might say. Ditto for our controls, because obviously you have good taste.

    But what about other frameworks? Obviously we have ours for creating an ORM (eXpress Persistent Objects) or for creating an MVC type application (eXpressApp Framework), but there are some others out there, open source, that you might want to investigate to polish the user interface of your apps. Here's a brief selection and please note I don't pretend to be thorough here.

    CSS frameworks

    Let's start at the top, in your users' face, as it were. Cascading Stylesheets (CSS) have been the way to style to look and feel of your web apps for a long time. But did you realize that there were frameworks for CSS?

    Yahoo!, as part of their various developer products, have a CSS framework called YUI Grids CSS. No, not grids in the way we use the term, but grids that help you layout your web pages. There's a builder application that helps you explore the layouts you can create with the YUI Grids CSS, and you can get the HTML code once you've worked out a layout you like.

    A better one, in my view, is Blueprint CSS. Again it's a grid based framework that gives you the ability to go to 24 columns across. Before you go, what the..., let me explain that in general you merge columns newspaper style, you don't try and put 24 columns on the screen at the same time. The grids, if you like, allow you to layout your content as if you were in a graphics app ("snap to grid"). Blueprint also comes with some good looking (and consistent) font choices for your various HTML elements.

    JavaScript frameworks

    Moving through the presentation layer for web apps brings you up against JavaScript. With JavaScript you can do some really interesting effects, and provide some important user interactivity. But the whole question of browser support and the differences in the browser DOMs really make this hard, as if writing JavaScript well wasn't hard enough.

    There are, to be blunt, a great number of JavaScript Frameworks and libraries you really should be considering for your web apps. These frameworks will make your work incredibly easier since they will abstract away the problems you will run into and have to solve anyway. These are the ones that I've investigated.

    First up here is Yahoo again with their Yahoo! User Interface Library (That's what YUI means above). There is a whole boatload of JavaScript goodness in this library, all the way from manipulating the DOM, adding events, some lightweight controls, drag-and-drop, and so on, so forth. There's also a compressor for minifying your JavaScript, a profiler, and other tools. Best of all, the impact on the window global object boils down to a single object called YAHOO. Everything is in there, nicely namespaced.

    Next is a tiny library called Base. This is a really good library for creating a class model in JavaScript, especially if you are used to "classical" class modeling the way we do in C# rather than the prototypal modeling you find in JavaScript. It gets pretty close and is an amazing feat.

    If you prefer something a little more accepted and widespread, there's always Prototype. It has good class inheritance functionality through its Class module. Prototype has some excellent AJAX functionality as well, although you'd presumably be using ASP.NET AJAX. I don't know too much about its DOM manipulation features, because I much prefer the next framework in my list.

    The final one I'd like to talk about is jQuery. This is, essentially, a JavaScript library for manipulating the DOM (so it overlaps YUI and Prototype in that respect). In its latest incarnation (1.3.x), it is remarkably fast at querying the DOM (which is the precursor to doing a lot of other work with jQuery: you find some elements according to some selector values and then you manipulate them). There are other libraries that build upon jQuery, notably jQuery UI, which is a set of user interface widgets that use jQuery. Like YUI, jQuery has a minimal effect on the global object: just two global identifiers, jQuery and $, although you can turn off $ if you are using something like MooTools which also uses it.

    Presentation layer frameworks

    Did you know that there are frameworks that embed a browser in them so that you can create a desktop application out of a web page? The most famous is Adobe Air: it will package up the HTML, CSS and JavaScript from a web application to produce a fully functional desktop application. This desktop app can have full access to your file system, registry, and so on. Instead of publishing your desktop application on the web, you're publishing your web application on the desktop.

    This is kind of a mind bender in a way. The application is not displaying a web page from out there in internet-land, it is just using HTML, etc, as the presentation layer for a normal desktop application. In other words, this isn't Google Chrome's "Create Application Shortcut", which is just a way of using Chrome without the chrome for a particular web site.

    Adobe Air is downloadable for free, but in case you want an open source, no mega-corporation framework instead, try out Titanium.

    Of course, in the .NET world, there's WPF and Silverlight. Both of which we support with an ever-growing set of controls.

    So, go on, have some fun investigating frameworks for your next application and save some time by using them.

  • End-user help files for DevExpress controls and frameworks

    Back at our annual summit in January (it seems so long ago), we had a discussion about documentation, as we do every year. This year was a little different in that, once we had talked about the developer documentation for our products, we broached the possibility of doing end-user documentation. That is, providing help files geared towards those people who use the applications that our customers write.

    People learning at whiteboard We've been asked in the past for such end-user help and we've generally said "just copy what you want out of the help files you have". However, that is somewhat unsatisfactory: just the thought of all those customers doing exactly the same thing to the same sections of the help ("here's how to use the ribbon at the top of the window...") is enough to make us wince.

    So the documentation team has been doing some work to extract out the relevant information from our existing help files and make it read properly as end-user documentation. Our main goal here is to make it easy for our customers to use these help files in their own documentation. An ideal scenario is when you simply download these help files and use them as part of your application, as is.

    • We've made great efforts to remove all mention of DevExpress (sob, Smile), the names of our controls, Visual Studio, and other "technical/developer/geek" stuff like that from the text. We imagine end-users would be mightily puzzled by such techno-babble.
    • Since we don’t (OK, can't) mention our controls and their options, we can only describe the default or standard behavior. So if you don’t change much when you implement our controls in your app, you won’t need to do much editing of the text or deleting of unnecessary information.
    • We’re thinking of shipping four help files, one for each of the WinForms controls, ASP.NET controls, WinForms XAF applications, and ASP.NET XAF applications. So, if you’re building a WinForms app using all our controls, you can simply include the WinForms end-user help file into your app.
    • We’re thinking of shipping CHM files, which can be easily edited with Microsoft HTML Help Workshop. It’s a free download, you can easily get it here. If you have other software that can decompile CHM files then by all means use it instead.

    We need some feedback though. Although we think we've understood the scenarios correctly, we're sure that you'll have some ideas and thoughts that we haven't considered.

    • We believe that providing CHM files will be the best way of deploying this end-user documentation. For those customers who don't want to edit or recompile, it's by far the best solution: download and deploy. I imagine this scenario will be the 80% case. For those that do, however, decompiling into HTML is simple enough to do, from which you can edit and recompile. Thoughts? Are there any other formats you'd prefer instead of CHM files?
    • Although we're thinking of having a comprehensive help file for, say, the WinForms controls, perhaps this would be confusing to the end-user of your app if you haven't used all of the controls we provide. Should we instead have one help file per product, so that there's a help file for XtraGrid, one for XtraTreeList, and so on? This would raise the probability of you having to do some work in editing/stitching the help files together. Is that worse than having to decompile the mega-help-file, remove the text for some control you haven't used, and recompile?
    • All I've been talking about so far is readable documentation. Is it the case that you'd also like screencasts that show off the control for the end-user? The problem I foresee here is that to do this we'll have to create a small app (or just use one of the demos), and that this demo app will look nothing like your app. This may, in and of itself, confuse your end-users more than it helps. (And, no, we don't have the resources to record a screencast just for you Smile.) Thoughts?

    We're very close to releasing these end-user help files. Final proofing is going on, and we're readying a new EULA for them, so there's not much time to tell us your thoughts. So let us know today!

  • Code Issues for JavaScript in CodeRush

    One of the features we're spending a good deal of time on is the Code Issues technology in CodeRush. Actually that's a bit too fine a line I'm drawing: we're feeling good about the Code Issues, it's improving the memory footprint and speed that we're spending a lot of time on. After all, if CodeRush takes up too much room, or takes too long, you won't care about it spotting any issues in your code, you'll be fuming at the delays or the need for more memory. I must say that the current "official" release is already light years ahead of the previous one for my coding.

    imageAnyway, Mark will be talking more about all this in the weeks ahead. My intent here is to think about code issues in JavaScript, ready for a later version of CodeRush (the initial Code Issues will be for C# and VB). What are some of the issues we should be detecting?

    JavaScript is a funny old language: it looks like Java or C#, but generally knowing either and then using JavaScript will lull you into a false sense of security. It's different. It also has a very good functional programming base. I enjoy puzzling it out, and these are some of the things that I think we should be highlighting since they've tripped me up.

    Scope. Just because JavaScript looks like a lightweight C# doesn't mean that it works the same way. One big, major, huge difference are the scoping rules. In essence, JavaScript uses function scoping. And that's it. No block scoping at all. Coupled with the ability to define a new variable at will, this means we may write code that doesn't work the way we think. An example:

    var foo = {
        a : 7,
        bar : function() {
          a = 14;
    alert("the value of a is " + foo.a);

    What is the value displayed by the alert() call? Give yourself a bonus point if you said 7. The reason is, of course, that the a variable in foo.bar() is a brand new variable and isn't the one in the foo object . Actually this example gives us another code issue:

    Global pollution. Back to our previous example, the new variable a is declared where, exactly? All variables belong to some object, so what owns a? The bar() function? Another bonus point, if you said the global object, which in browsers is window. In fact, you can add the following line after the previous call to alert() to show the value of that brand new a:

    alert("the value of a is " + a);

    And it will show an alert box with the value 14. Any declaration of a variable without a var keyword will add that variable to the global object, and that's usually not what you want (the exception is when using the JSON format like foo.a above, but that's a special case). In fact, most JavaScript that's written creates all kinds of global objects, mostly functions: it's really hard to condition yourself not to do so (because, for one reason, in doing so we can avoid issues with the JavaScript scoping rule). And the problem about creating and using global objects is that we can all too easily stomp over someone else's global object with the same name.

    Declare before use. Another result of the ability to so easily create a variable on the global object is that we should declare variables before we need them. Sounds obvious? But, wait: one of the results of function-scoping is that a variable declared anywhere in a function is visible everywhere in the function, even before its declaration. So If we changed foo.bar() to:

        bar: function() {
            a = 14;
            // do stuff with a
            var a = 0;

    Then our second alert() call would fail with the error that a was undefined. So, in JavaScript, we should always declare a variable (with the var keyword of course) before we use it: it helps with the maintainability of the code.

    Don't fall through with switch. Haven't run into this particularly myself, maybe because C# has conditioned me to always have a break or other jump at the end of each case in the switch statement, but JavaScript doesn't have the same limitation. In the vast majority of cases (pun intended) not having a break is the wrong thing.

    Equality. JavaScript has two equality operators, ==, and ===. The latter one (the identity operator) is usually the one we really mean, especially we were coming from C#. Ditto for the not-equality operators, !=, and !==. The problem with the familiar operators is that they will attempt to coerce/convert one of the sides to the type of the other, which is usually what you don't want. On the subject, unlike C#, JavaScript will let you get away with "if (a=b)" without a murmur, so we should flag that one.

    Auto-adding of semicolons is bad. This is downright weird, but semicolons at the ends of statements are optional. JavaScript will add a semicolon to your code as it parses it if the interpreter thinks one is needed. However, don't be lazy and always add your own semicolons. The best example of why this could be an issue is the return statement to return a value from a function. Suppose I wanted to return an anonymous function from another function and wrote the following:

                function() { 

    What would be the return value? The anonymous function with the alert()? Or undefined? Another bonus point if you said the latter. The issue is that the return statement is assumed to be a single line (unless some code structure is started but not finished) and JavaScript will have added a logical semicolon after the return keyword. The anonymous function would be dead code. That return statement should be

            return function() { 

    For those who have been coding for a while in JavaScript, I'm sure that none of this is news to you. But for those who are starting out, code issues like these being flagged in your code would make your life immeasurably easier.

    Have you got any more JavaScript code issues? Let me know. I have some more, but this post is long enough already.


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