ctodx

This Blog

News

Favorite Posts

Archives

April 2011 - Posts

  • Sneak peek: New WinForms Document Manager control provides tabbed and MDI views (coming in v2011.1)

    In v2011.1 we will be adding a new DocumentManager control to DXperience WinForms. This new control has been designed as a drop-in replacement for the older XtraTabbedMdiManager control, providing pretty much the same features (and interface) as the older control but with further enhancements and support for dock panels. Using DocumentManager, you will be able to completely emulate the document interface found in Visual Studio and be able to create rich interfaces easily with little to no coding at all.

    Let’s take a look under the hood. Here’s what you’ll get:

    1. The ability to display MDI child windows either as tabs or windows. DocumentManager supports two views, known as Tabbed:

    DocumentManager Tabbed View

    and NativeMdi:

    DocumentManager Native Mdi view

    2. Full integration of DocumentManager with our dock panels (created using the DockManager component). Without any coding on your part, your end-users can dock windows onto the tab area using drag-and-drop, just as you’re accustomed to doing with Visual Studio:

    DocumentManager Dock Panel Drag-Drop

    Since we’ve made sure that the existing interfaces of XtraTabbedMdiManager are replicated in DocumentManager, it is easy to replace your instances of XtraTabbedMdiManager with DocumentManager and immediately get the benefits of this integration of dock windows and the tabbed view.

    3. Context menus with the common docking operations. We’ve built them in, so you don’t have to write your own:

    DocumentManager Context Menu

    4. Ability to split the document area with tab groups. Either using a context menu or by simple drag-and-drop, your end-users can create horizontal or vertical tab groups and resize them with a built-in splitter control:

    Document Area Splitter

    To which I can only say, this is one very nifty component.

  • Sneak peek: Visual Studio dock style for VCL docking library (coming in v2011.1)

    We have implemented a new dock style for our ExpressDocking Library: the Visual Studio look and feel (suggestion: DS2222). Here it is in action:

    Visual Studio docking style

    (Click to enlarge.)

    Switching the dock style can be performed via the newly introduced DockStyle property of a docking manager instance (TdxDockingManager). The property values are dsStandard (the current behavior and default value) and dsVS2005 (the new style).

  • Erudite Programming (Message from the CTO, newsletter 46)

    I wrote this message a good three months ago, but at this remove I can’t remember the exact situation that prompted it.

    41 incunabulumphoto © 2010 Eric Bryan | more info (via: Wylio)Erudite programming

    We developers have a lot on our plate. There's the design of the software, the decisions to make with regard to the best way to create the software (the infrastructure, third-party libraries, language), the writing and running of the tests (and hopefully using the tests to drive the design, etc), the implementation, the continual need to keep up to date with what's going in our field, and so on so forth. Isn't that enough? Aren't we, like, super-heroes already?

    To my mind, no. There's another area we should pay some attention to: verbal and written communication.

    Consider this: we are, like it or not, the intermediaries between a highly technical jargon-filled field and the rest of the world. To get our jobs done, we have to be able to communicate our ideas, discuss requirements with end-users and business stakeholders, request infrastructure improvements and upgrades, all from people who, essentially, are paying our salary. The other aspect is that we have to convey through comments the whys, whats, and hows of the things we did to the developers who will be maintaining our code. And, more often than not, that maintenance programmer will be ourselves.

    It behooves us, then, to learn to write well, to express ourselves as best we can. The better we do it, the better our environment becomes.

    But, how? Unfortunately, unless we already have a natural talent for such communication, we have to learn. In reality, it's not that difficult and like everything, it just requires practice. Lots of it. I wrote my first article for a magazine in February 1992, 19 years ago, and I've been writing articles and posts ever since. Start a blog (posterous and tumblr are easy to set up) and write something regularly. Once a week, on topics that interest you. Review a movie you saw or a book you read. Write about the issues you encountered in your work and how you solved them. If nothing else, that'll serve as a memo to your future self. Jeff Attwood also recommends joining StackOverflow and answering questions there, but then again he would say that, wouldn't he?

    Let's become more erudite. And then we really will be super-heroes.

    (You can watch the video here.)

    I remember hating writing essays at school, probably because the topics were forced on us. It has only been since I started working that the whole concept of writing long form material became more palatable, and of course nowadays it’s easy to publish your content. And – honestly – the only way to improve your writing skills is practice, practice, practice. Takes time, yes, but verbal and written communication are essential to modern software development. An ability to write code is great, but you can only advertise that code by writing and talking about it. So… get to it!

  • DevExpress newsletter 45: Message from the CTO

    Boy oh boy, Jeff and I had fun videoing and editing this one: Duck typing.

    Duck Typing

    If you've done any programming with a loosely-typed scripting language for a while -- languages like JavaScript for example -- where the cost of declaring and creating some object is virtually free both in terms of programming resources (the amount of code you write) and run-time requirements, then you will certainly have run into duck typing.

    Imagine that you have a function which expects a duck object. However in this method all that's really required is the Walk method of the passed in object, the Swim method and the Quack method. The function doesn't care if the object has a Bill property or a Feathers property or anything like that; it just wants to ask the object to Swim, Walk, and Quack. If the object can't do one of these things then a run-time error is raised.

    In essence what's happening here is exemplified by the following saying: "if it walks like a duck, swims like a duck, and quacks like a duck, then I call that thing a duck."

    Now you may say that duck typing is a little too dangerous to use. An example is a function expects an object with a Cleave method. In certain scenarios, Cleave may split something apart, and in others stick something together. The behavior changes according to the object passed in. In reality such issues are rare and can be avoided by proper testing.

    The other thing to grasp is that duck typing is all about viewing object-orientation in terms of message passing, not about designing and implementing some class and interface model. It is ideally suited to a dynamic programming language with loose typing and provides a basic form of polymorphism without the verbosity and strict typing of an inheritance class model.

    If you program in JavaScript or Ruby or Python, I would recommend that you eschew standard class-model-based object orientation and embrace the freedom of duck typing.

    Not much more to say really. When objects are easy to create and configure (that is, without all the paraphernalia of a class model behind it), duck typing will be prevalent.

    (You can watch the video here.)

  • Webinar wrap-up: Julian on JavaScript - reading underscore.js

    This was kind of an experimental webinar: take some well-known library and read to code to see what we can learn from it. I’m a firm believer in learning tips and tricks, as well as syntax and shortcuts, from reading some well-written (or even badly-written!) codebase.

    I chose underscore.js for this first experiment mainly because it’s a set of utility functions that’s pure JavaScript and that doesn’t use the DOM. I would download it and follow along with the video (URL to come, but it’ll be on DevExpress Channel) and with my notes here.

    1. The source is structured like this:

    (function() {
      // do some work
    })();

    A common JavaScript pattern: auto-executing anonymous function. The reason it’s wrapped in parentheses is so that the JavaScript interpreter doesn’t think that you are declaring a function statement: function foo() {}. The whole of underscore is inside this function, hence any local varaibles defined within it will be visible throughout this function, but not outside. Also any nested functions will also see this function’s locals.

    2. First statement gets and saves the global object:

      var root = this;

    The this variable points to the global object because the outer anonymous function was called using the function invocation. (In essence, it was not called on an object via the dot syntax, which is method invocation.) So we’re saving a reference to the global object. The reason for doing it this way, rather than, say, using window is that this code can also be used on the server, where the global object is called something else.

    3. The we save the current value of the ‘_’ global variable. ‘_’ is the main entry point to all of underscore’s functionality. (Yes, it looks weird, so I shall use underscore.) If you are using another library that uses ‘_’ then we’re about to overwrite it. Underscore therefore gives you a way of getting it back: the noConflict method. It’s defined like this:

      _.noConflict = function() {
        root._ = previousUnderscore;
        return this;
      };

    If you call it, you will get back the underscore object (actually, as we’ll see, it’s a function).

    4. Next we have a bunch of code that sets up a set of local variables that point to standard functions and methods. The reason for this is (a) less typing, and (b) more speed. Every time, JavaScript has to resolve something like “foo.bar.baz” it has to search the invocation object (a hash table, like all objects) for “foo” (when you call a function JavaSxcript sets up a special object called the invocation object that holds the locals, etc.). Once it has a reference to that, it then has to lookup and find the “bar” object. Once it has that, it then has to look up and find the “baz” object. Agreed they’re hash table lookups, but it’s still slower than being able to compile to a static pointer.

    5. Now we get the creation of the ‘-‘ object itself.

      var _ = function(obj) { return new wrapper(obj); };

    This is where I complained that the convention in JavaScript is to name constructor functions with an initial capital letter. This is a mnemonic to help programmers realize that they can’t call the function directly, but have to use the constructor invocation (that is, with “new”). So, –1 for underscore there. But note that ‘_’ is a function, not an object, although later on we will be adding methods to this function.

    6. This is where we expose the local ‘_’ function globally:

        root._ = _;

    7. And now we come to each/forEach:

      var each = _.each = _.forEach = function(obj, iterator, context) {
        if (obj == null) return;
        if (nativeForEach && obj.forEach === nativeForEach) {
          obj.forEach(iterator, context);
        } else if (_.isNumber(obj.length)) {
          for (var i = 0, l = obj.length; i < l; i++) {
            if (iterator.call(context, obj[i], i, obj) === breaker) return;
          }
        } else {
          for (var key in obj) {
            if (hasOwnProperty.call(obj, key)) {
              if (iterator.call(context, obj[key], key, obj) === breaker) return;
            }
          }
        }
      };

    This is the fundamental function in the whole of underscore. If you look through the source, you’ll see calls to this function (usually using its local name, each) all over the place. Worth exploring this code, in other words.

    8. I went off on a tangent here about the use of “==” in this code. Essentially, I’ve learned that it’s bad to use “==” since coercion of the types either side of the operator can and will happen when you least expect. It turns out that if obj is either undefined or null, the condition is true, but it’s false otherwise. A handy trick to know, although I may find that I don’t use it.

    9. What the heck is breaker? Turns out that it’s a dummy object returned by internal uses of each to break out of the loop early. (Check out every and any for where it’s used.) It’s a neat use of a dummy object, something that any outside code can’t use or misuse.

    10. Notice that if we are iterating over an array (or an array-like object) we use for, but over an object, we use for..in, and make sure we call hasOwnProperty to identify the ��local” properties and not those inherited through the prototype chain.

    11. I found invoke interesting because it allows you to pass in any number of extra parameters to the method you call on every element.

      _.invoke = function(obj, method) {
        var args = slice.call(arguments, 2);
        return _.map(obj, function(value) {
          return (method ? value[method] : value).apply(value, args);
        });
      };

    Since the invoke method requires the first two parameters itself, we have to remove them to create our own arguments array that we then “apply” to the method call. We do this via the slice function, which, if you follow it back, comes from the Array prototype. Nifty.

    12. The rest of my notes were kind of minor, although I did like the implementation of isNaN since it makes use of the fact that NaN is the only value in JavaScript that is not equal to itself.

      _.isNaN = function(obj) {
        return obj !== obj;
      };

    And similarly isBoolean since there are only two possible values.

      _.isBoolean = function(obj) {
        return obj === true || obj === false;
      };

    All in all, a nicely written library, I feel. The only two things I’d change would be the name of the constructor function wrapper and (possibly) the name of the global object ‘_’. That last one just looks weird to me, even now.

    So, did you find the premise of this webinar interesting? Reason I ask is, at the end of the month, I’ll be doing the same with jQuery, so let me know if you’d like a different approach or not.

  • Sneak peek: improvements for the VCL pivot grid (coming in v2011.1)

    The VCL team are readying the VCL subscription v2011.1 Release Candidate for this week. Depending on customer feedback of this RC, we shall be releasing the actual v2011.1 soon thereafter.

    In this RC, there have been a few improvements to the pivot grid.

    1. There is a new compact layout for the grid, aimed at improving the user experience. Here’s the before and after look and feel (click for the full image):

    CompactLayoutStyle

    You activate it by setting OptionsView.RowTotalsLocation to rtlTree.

    2. We’ve added a new Advanced Customization Form, to allow users, especially advanced users, a way to more easily customize the look of the pivot grid.

    CustomizationForm

    3. Not only that but we’ve improved the access to the normal customization form and the advanced form, by allowing them to be embedded in the pivot grid.

    CustomizationFormEmbedded

    You can use the slider to the left of the grid to cover or expose the embedded customization forms.

  • Sneak peek: improving the performance and memory footprint of Excel and PDF export from WinForms grid (coming in v2011.1)

    Through valuable customer feedback and our own testing, we realized that our exporting engine wasn’t all it was cracked up to be, especially with regard to raw performance and memory usage. The call went out: increase the performance, and, at the same time, reduce the amount of memory used. I’ve now received the results of our benchmark and it’s time to reveal all.

    photo © 2008 Nathan | more info (via: Wylio)What we used. The latest version of DXperience v2010.2 and the current internal alpha build for DXperience v2011.1.

    What we timed/measured. We used 4 benchmarks:

    1. XtraGrid with 50,000 records and 5 columns (1 integer, 1 date, 1 text, 1 float, 1 checkbox). A quarter of a million cells.
    2. XtraGrid with 100,000 records and 5 columns (1 integer, 1 date, 1 text, 1 float, 1 checkbox). Half a million cells.
    3. XtraGrid with 50,000 records and 20 columns (1 integer, 1 checkbox, 18 text with random contents, between 8 and 10 chars). A million cells.
    4. XtraGrid with 100,000 records and 20 columns (1 integer, 1 checkbox, 18 text with random contents, between 8 and 10 chars). Two million cells.

    The platform. Reasonably standard developer box running Windows 7, 64-bit. (32-bit can’t process this amount of data.)

    The results.

      v2010.2 v2011.1 % change
      Mem (MB) Time (sec) Mem (MB) Time (sec) Memory Time
    50k rows * 5 cols
    xls 540 126 117 7.5 -78% -94%
    xlsx 743 152 146 8.2 -80% -95%
    pdf 485 162 40 37.0 -92% -77%
    preview 480 122 32 4.9 -93% -96%
    100k rows * 5 cols
    xls - - - - - -
    xlsx 2416 741 206 16 -99% -98%
    pdf 963 573 80 73 -92% -87%
    preview 956 447 65 9 -93% -98%
    50k rows * 20 cols
    xls 3016 637 476 28 -84% -96%
    xlsx 6073 2721 595 35 -90% -99%
    pdf   >3000 163 128   HUGE
    preview 2848 610 130 17 -95% -97%
    100k rows * 20 cols
    xls - - - - - -
    xlsx   >3000 997 74   HUGE
    pdf   >3000 316 264   HUGE
    preview
    >3000 265 32
    HUGE

    Notes: OK, so we got bored on some of the tests with DXperience v2010.2. We basically abandoned the test if it took more than 50 minutes (3000 seconds). To be honest, we have better things to do. So where it says HUGE, assume it means the percentage change was between –99% and –99.9999%.

    Together with these performance and memory improvements, we’ve made some small UI changes:

    • We’ve added the ability to show progress for export/print/preview:

      ExportProgress
    • It also has the ability to provide a Cancel button to halt the process:

      ExportProgressCancel
    • For the new Instant Feedback UI, we’ve added a marquee progress bar for when the grid is loading data from the server:

      LoadingMarquee

    We’ve also made some changes to help with exporting to Excel. Selected editors (CheckEdit, ImageComboBoxEdit, ColorEdit) will now export a textual representation rather than an image, as before. So for example, in v2010.2 and earlier, if you exported the contents of a CheckEdit column, you would get this:

    CurrentExportCheckbox

    Where the cells are images. Actually that’s not quite right, there was an issue where, if you deleted the column, the images would remain (wacky but true):

    CurrentExportCheckboxError 

    Anyway, forget all that because from v2011.1 onwards, you will get this:

    NewExportCheckbox

    Stay tuned for more WinForms news in DXperience v2011.1.

  • Advance warning: “Julian on JavaScript” analyzing underscore.js on Monday

    Spannersphoto © 2007 Les Chatfield | more info (via: Wylio)Yeah, I know it’s April 1 today, but this is no joke. As part of my Julian on JavaScript series of webinars, I’m going to be reading and dissecting the underscore.js codebase on Monday, so that we can learn from it – good or bad – and apply that knowledge to our own JavaScript code. underscore.js is a great little pure (that is, non-DOM-related) JavaScript library that extends standard arrays, objects, and functions with some nifty methods. Register here for the webinar and come watch the spelunking.

    This webinar will be one of those with, oh, roughly, at a wild guess, two slides in the slidedeck: the cover and the acknowledgements. The rest of the show will be in Visual Studio and Firebug and maybe jsFiddle. Hard-core hands on.

    Of course I’ll be writing a wrap-up blog post afterwards here on ctodx. But you’re going to have to watch this one for sure.

LIVE CHAT

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

FOLLOW US

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