ctodx

This Blog

News

Favorite Posts

Archives

June 2011 - Posts

  • Webinar wrap-up: Julian on JavaScript–using jQuery with DevExpress ASP.NET controls

    When I originally proposed this webinar I thought the topic was doable in a single session. It turns out I was way too optimistic, not only did I have to draft Mehul in to help (he knows way more about our ASP.NET controls than I do), but we also decided that the subject deserved a couple more to give it justice. So this particular presentation turned into a “basics” webinar; we’ll cover other ideas later on.

    Construction Signsphoto © 2008 jphilipg | more info (via: Wylio)You can watch the webinar here. The slidedeck is here.

    UPDATE: Mikhail in the ASP.NET team was kind enough to point out a couple of issues and some extra information. Look out for the UPDATE markers in the text below.

    Basics

    Speaking broadly, jQuery has two main uses: finding elements, and doing something to those elements (for example, changing values, properties, and attributes, and animating them). DevExpress ASP.NET controls have some of the same features, and our recommendation is that it’s best to use the built-in support whenever possible. Don’t fight it just to trumpet that you’re using jQuery, use what we already provide whenever possible.

    If you find that jQuery with the DevExpress controls is hard, jQuery UI adds a whole new complexity layer on top. To be blunt: if you don’t pay attention, you’ll find yourself battling between what jQuery UI wants and what the ASP.NET controls want. An example of this is B144365. (UPDATE: we’ve updated this report to make it more readable and understandable. Ditto B142903, referenced within that report.)

    Basic issues

    1. DevExpress ASP.NET controls don’t use jQuery (whereas our ASP.NET MVC extensions do). That means that you will have to remember to add a script element to load jQuery. Best place for it is in the website’s master page, to ensure jQuery’s loaded for all pages.

    <script type="text/javascript" src=http://ajax.microsoft.com/ajax/jQuery/jquery-1.6.1.min.js></script>

    Here, I’m using Microsoft’s CDN (Content Delivery Network) to load it, but of course you can use a local copy or Google’s API for loading JavaScript libraries.

    2. How do you find the right DOM element? ASP.NET controls have a complex algorithm to name HTML elements. Our controls sometimes (or maybe, often) create a set of HTML elements in a container hierarchy for a single ASP.NET controls. My advice here is to not try and guess the id of an element (or the classes to which it belongs), but to look at the source code for the page. Find the HTML rendering for the control and use that to understand the relationship between the container(s) and the input control(s) and other elements. Mehul also pointed out you can use the developer tools for your favorite browser to determine the same information.

    I’ll note that sometimes it’s possible to use the client-side ClientInstanceName() function at run-time to determine the id of the element. (UPDATE: ClientInstanceName is a property not a function.) We’ll see an example of this later.

    3. When should you set up bindings? Normally in website programming with jQuery you use the document ready function to set up bindings to event handlers and the like, since you know all the elements have been created. So you write a function to be executed with jQuery(document).ready(myFunction) function or the simpler $(myFunction). Easy enough, but it must be emphasized that DevExpress controls have some special initialization that may not be complete at document ready time or that executes after your document ready function (remember the ASP.NET controls don’t use jQuery, so their special “document ready” code may execute before or after jQuery’s).

    (Aside: in essence there are several parts to a DevExpress control at run-time. There’s the HTML DOM element (or elements). There’s also the client-side JavaScript object that takes care of communication between client-side and server-side. And there’s the server-side object defining the control’s behavior. It is the JavaScript object that may not be fully initialized at document ready time.)

    In certain cases, it may make sense to catch the Init event of the controls’ ClientSideEvents object to set up your bindings to jQuery.

    4. Unobtrusive vs. obtrusive JavaScript. The modern style of using JavaScript on a web page is to use it unobtrusively. All event handlers and special JS functionality are attached at run-time by JavaScript code. This is the ideal, but of course ASP.NET apps don’t follow this at all: they all embed code in the middle of the HTML, mixing content with behavior. If you like, this is old-style JavaScript. Be aware that our controls will use obtrusive JavaScript and plan/test accordingly when you add other handlers via jQuery.

    5. Losing jQuery bindings after callbacks. Be aware that DevExpress controls will rebuild parts of the DOM after a callback (for example, paging down in the grid). Your carefully crafted bindings will be lost since the DOM elements they were attached to have gone away, even though the control “looks” the same after the callback. We recommend you peruse this sample: E3324.

    Simple example 1

    • Drop a textbox, label, and button on form
    • Clicking the button will post the entered text to the label and refresh the page
    • Using jQuery:
      • If textbox is empty, show “Enter data” in it
      • If textbox gains focus & is empty, remove that text
      • If textbox has value, just show value

    Let’s take it step by step. This is the first time we'll be discussing what is being rendered.

    UPDATE: We already have this feature built into our ASPxEditors. It’s known as NullText or Watermark.

    Set the button's Click handler to

        protected void ASPxButton1_Click(object sender, EventArgs e) {
          ASPxLabel1.Text = ASPxTextBox1.Text;
          ASPxTextBox1.Text = "";
        }
    You can run the app, and see that it works. Whatever you type into the textbox is reflected in the label when the button is clicked. It uses a postback. View the HTML source for the running web page. Note that the actual HTML input field is in a <table> container and the container has the id we’d expect, whereas the input field has a different id.

    Add the jQuery script element above to the master page. Write the document ready script at the bottom of the ASP.NET body content container:

    <script type="text/javascript">
      $(function () {
    
      });
    </script>

    Now for the first line of code:

        var textBoxId = "<%= ASPxTextBox1.ClientID %>";
        alert(textBoxId);

    What's happening here is that we're using ASP.NET to fill in the actual id for the textbox. We don't want to "calculate" it in the script; let ASP.NET do it for us. Run the app to see the alert. We're getting there.

    Now to get the container (delete the alert – it was just to show what the id looks like).

        var textBoxContainer = $("#" + textBoxId);

    Now to get the HTML input field:

        var textBox = textBoxContainer.find("input");

    Now for the (fairly simple) code:

        var isEmpty = true;
    
        var setValueWhenEmpty = function () {
          if (textBox.val()) {
            isEmpty = false;
          }
          else {
            isEmpty = true;
            textBox.val("Enter data")
          }
        }
    
        textBox.bind("focus", function () {
          if (isEmpty) {
            textBox.val("");
          }
        });
    
        textBox.bind("blur", function () {
          setValueWhenEmpty();
        });
    
        setValueWhenEmpty();

    Run to show it in action: when the textbox doesn't have focus and is empty, "Enter data" is shown. Focus it and it becomes blank. If it has a value, it’s always displayed.

    If you give the textbox control a ClientInstanceName (say, myTextBox), you can change the initial code as follows:

        var textBox = $(window.myTextBox.GetInputElement());

    That is, the code for the control will create a JavaScript object called myTextBox, and you can use the GetInputElement() function to return the DOM element for the input field. After that, just call jQuery on the DOM element to return the jQuery object for the input element. After that, we can use the same code to bind focus and blur (the blur event is the DOM’s name for the unfocus event).

    Summary: we've seen how to identify elements in an ASPX page created with DevExpress controls and how to add event handlers to the required elements, all using jQuery.

    Simple example 2

    We’ll build on the example we just made by getting the label to flash when it is initially shown.

    Show the source for the running app and note how the label gets rendered. This time there's no container to worry about.

    Color animation is done through jQuery UI: it extends the basic jQuery animations to include color. So we need to add the jQuery UI JavaScript file to the project's Scripts folder (or you can use a CDN), and then add it as a script tag to the master page using drag/drop.

    Add the following code:

          var labelId = "<%= ASPxLabel1.ClientID %>";
          var label = $("#" + labelId);
          var origBackColor = label.css("backgroundColor");
          var origColor = label.css("color");
    
          if (label.html()) {
            label.animate({
              backgroundColor: "#DC574E",
              color: "white"
            }, 2000, function () {
              label.animate({
                backgroundColor: origBackColor,
                color: origColor
              }, 500);
            });
          }
    In other words: get the id of the label, get the jQuery object for that id, save the current fore and back colors. If the label has some text, animate the colors to something more visible and, on completion of that animation, animate them back to the original colors.

    Summary: jQuery UI needs us to add the custom JS file to our Scripts folder. Again we reinforce the plan of attack: look at what's originally rendered to understand the structure, use that knowledge to get at the right DOM elements and manipulate them using jQuery.

    Complex example

    Mehul presented a great example using jQuery with the ASPxGridView: highlighting the just-edited-and-updated row. You can read about it here.

    Interesting jQuery-with-DevExpress examples

    The support team are adding jQuery examples regularly. Here are some of the more interesting ones:

    • E3324 – binding jQuery to data cells
    • E3325 – Attach jQuery UI AutoComplete to ASPxTextBox
    • E1810 – drag/drop from one ASPxGridView to another using jQuery UI library
  • Delphi and C++Builder devs: VCL Subscription v2011.1 now released

    If you are an active VCL subscription license owner, the DevExpress Downloads page (http://devexpress.com/downloads) has been updated with the official v2011 vol.1 release. You can download and install it immediately.

    Gearstickphoto © 2004 Frank Waaland | more info (via: Wylio)The sales system has also been updated to reflect the various options available for promoting  your licensed products to a subscription version or to upgrade to a subscription pack. If you require direct assistance with the renewal/upgrade costs for your particular mix of products, email us at clientservices@devexpress.com or call us at +1 (818) 844-3383 between 8:30am and 5pm Pacific Time.

    I will also note that the next minor version (v2011.1.4) is scheduled to be released within the month.

  • VCL product subscriptions: listening to feedback

    We’ve had a lot of extremely valuable feedback from my previous post about our plans for our VCL product line, both as comments to the post itself and as emails to me. I want to thank everyone who did respond: we’ve looked at and discussed all of them. And by “we”, I mean both the management of DevExpress and the VCL team, since we are all here together this week in our development offices in Russia.

    Why subscriptions again?

    Firstly, we feel that we didn’t communicate effectively (and by “we” here, I mean me, obviously) what our reasons were for moving to a subscription model. Let me take an aside here to explain.

    As part of a license to a DevExpress product you get the right to create as many applications with that product as you want for as long as you want. Furthermore we will provide support services as part of that product for as long as you use it. We’ve delivered on that promise again and again.

    However, what we have found over the past few years is that a greater and greater amount of support is being spent on version incompatibilities. We’ve tried hard in the past to provide support to people who want to use product X from a couple of versions back with the latest version of product Y, given that both X and Y use some of the same underlying codebase (simple example: using an old treelist with the latest grid, given they both use the same editors). Since this support invariably requires input from the development team, the upshot is that, overall, we are spending too many resources on issues that affect only a small proportion of our customers; resources that, frankly, we should be putting towards creating new features and new functionality. The same goes of course for the original development of new features: explicitly allowing interactions between just two different versions of our controls at the outset exponentially increases the amount of testing we have to do for a release.

    If we had a system whereby customers were guaranteed to get the latest versions – were encouraged to keep up to date, if you like – we could spend more time in producing compelling updates on a regular twice yearly cycle, and less time on such cross-version issues. If we had a system whereby customers could get new minor features quickly and regularly, the less time they would have to wait for a major version update before being able to update their apps. The current system does not facilitate these goals at all, hence the idea of moving to a subscription model. Naturally a subscription model not only helps our customers budget their annual expenditures on controls, but also allows us to budget what we allocate on producing and supporting VCL products.

    What should subscriptions apply to?

    And so to my next point: one of the biggest complaints raised by people is that the proposed subscription packs were too coarse-grained and that the packs didn’t address their particular needs. (OK, we did briefly discuss adding a couple of new packs to try and alleviate the problem, but, to be honest, we abandoned that line of discussion pretty quickly.)

    Hence, we are proposing to make the individual products subscription-based as well.

    If you are buying our VCL controls new, you have the choice of purchasing a subscription pack if you require a spread of controls, or of buying the individual products you need on a subscription basis. Prices for new product purchases are the same as now, annual maintenance renewals will be 40% of original price.

    If you already have licenses to some of our products, you can promote them individually to the subscription-based v2011.1 version. The price would be (essentially) 40% of the list price if your version is the current latest version; 70% if you’re one version back; 85% for two versions back; or full price any older than that. Of course, if you find that a subscription pack is more to your liking, you can promote to the same ones I discussed (and at the same prices I provided) last time. All subscriptions are renewed on an annual basis.

    I will re-emphasize my first point again here, though in a different way: v2011.1 (and later) will not be “cross-version-compatible”. If you decide to promote at least one of your VCL products to v2011.1, you will have to promote them all if you want to use them in the same IDE and for the same applications. We cannot provide support for using a v2011.1 control with an earlier version of another control. The new installer will continue to remove earlier versions of controls for compatibility reasons.

    Oh and by the way…

    Finally, we found that we don’t really know what kinds of development you, our VCL customers, are doing. Apart from some raw sales numbers, we don’t have much relevant data. For example, we don’t know

    • whether you are maintaining legacy systems or writing new ones or thinking of moving to new platforms;
    • whether you are old-time Delphi devs or new customers using Delphi for the first time;
    • whether you are writing in-house programs or retail applications;
    • what you are planning on doing with Embarcadero’s promised new features, if anything.

    Hence we will be contacting all of you individually over the next month or so to survey your environments, usage patterns, future plans, and so on. The hope here is that by knowing more about our market, the better we’ll be at satisfying that market’s future needs.

    Summary

    In short: products are purchased by annual subscription, upgrade options for existing product owners, same subscription packs, no cross-version code from v2011.1 onwards, surveys to come.

    Apart from all that, we are altering our sales system’s business rules to support this new proposal. Once that is done and the website updated, we will release.

  • Multitasking (Message from the CTO, newsletter 49)

    For one reason or another, Jeff and I ran out of pre-videoed messages this time, so this one is “text only”.

    Multitasking

    It’s been such a long time that we’ve been using PCs that multitask well that we don’t even think about it any more. It’s still magic in a sense: the OS will halt a process, save its state perfectly, swap in another process, restore its state, and kick it off. A couple of milliseconds later, another process is running as if it had never been stopped. 100 processes in my Task Manager? Yawn, shhh, pass the popcorn, I’m watching a movie on my PC.

    Microwave Timerphoto © 2009 Pascal | more info (via: Wylio)But there is one place where multitasking is not so smooth and automatic and causes problems every time it happens: our own concentration. Just like our PCs, every time we have to multitask (our boss phones us as we’re trying ever so hard to debug something intricate) we have to save our state somehow. If you’re anything like me, it’s not a case of “oh, hang on, let me write down where I was, what theory I was testing, the results so far that have validated my theory”, it’s more a case of hoping your memory can remember all that and “yeah, I can pop round to your office; this’ll wait.” Of course there are other interrupts we must process: the appointment warning from Outlook about that meeting, the “toast” window popping up telling us that we have a new email or that a colleague has logged into the IM app.

    Our state-saving expertise is woeful. Which is why, when we have to context-switch, it takes us so long to get back up to speed. I think the generally accepted and quoted figure is that it takes us 15 minutes to get back into the groove. So what can we do to reduce context switches and make our multitasking run smoother? Obviously, there’s not a lot we can do about the “boss interrupts”, but we can mitigate them somewhat.

    The obvious one that everyone recommends is to turn off all interrupts: close down Outlook, your IM app, Tweetdeck, anything that “toasts” you or that intrudes on your work. Sure, we do that anyway.

    An equally important one is this: subdivide and break up your work into, say, 50 minute slots. This has several benefits: it allows you to attack various tasks throughout the day (we’re lucky indeed if we only have one task to do: most of us have meetings to attend, customer emails to reply to, code to design and write, presentations to give, and so on, tasks upon tasks) and give a feeling of progress in many of them, reducing that feeling of being overwhelmed. Timeboxing yourself like this also gives you a break at the end of the slot to reflect on what you’ve done, assess your progress, save some state by writing down some conclusions, etc. You’re never doing so much that you have several hours of progress to remember on an interruption. This is the basis of the Pomodoro Technique.

    Take it from me: stop multitasking. Do some async processing, not parallel.

    Hmm. Now I’ve written it and published it, it sounds like it comes from the heart. Learn from me!

  • VCL subscription and v2011.1 news

    (UPDATE: I've published some new information about our VCL plans here. By all means read this, but realize that there's more that's not covered here.)

    After some great feedback from you, our customers, and a bit of analysis on the data in our sales database, we’ve revamped our ideas on the subscription packs that we’ll be providing and have decided on upgrade pricing and the like. To recap, with the next major release of our VCL controls we’re going to move our licensing to an annual subscription basis and we’re going to be adopting the DXperience version naming convention (essentially year-dot-release, so the first one will be v2011.1).

    PlannerTo be clear, by subscription we mean that, when you purchase one, you get a perpetual license to use the controls in the product, lifetime support, and the right to all updates and upgrades for a full 12 months from the time of purchase. At the end of the year you can decide whether to renew the maintenance component of the license to get all the updates/upgrades for the next 12 months. If you don’t renew immediately, be aware that the renewal price increases on a month by month pro-rata basis until it reaches the full price again.

    Subscription packs

    First things first: the subscription product packs. We’ve added a new one from when I last spoke about this because it fits a lot of customers’ profiles and control usage. There will now be four packages.

    VCL Subscription. This is the same as we have now, for the same price ($1499.99) and annual upgrade price ($599.99). It comprises essentially everything we do for Delphi and C++Builder. This package attracts our priority support. No changes here.

    ExpressQuantumPack. Although this has the same name as a pack we currently ship, it has changed in two ways. Firstly, it’s now sold on a subscription basis. Secondly, we’ve enhanced its reach. The ExpressQuantumPack is now targeted at developers who want to use the preeminent VCL grid on the market to its best advantage. It comprises the ExpressQuantumGrid and data editors, the layout manager to allow you to easily and quickly create flexible forms, the printing and exporting library so that you can publish your grid data, and the skinning library so that you can produce that cutting-edge look-and-feel your users want. The first year price is $799.99, with subsequent years costing $319.99 annually.

    ExpressGridPack. This pack takes the controls in the ExpressQuantumPack as a foundation and adds the two remaining grid-like controls: the pivot grid (ExpressPivotGrid) and the tree list (ExpressQuantumTreeList). The first year price is $999.99; subsequent years are $399.99 annually.

    ExpressNavigationPack. This pack is for those developers who are not necessarily creating applications that display tabular data, but that still need basic functionality like ribbons, bars, menus, and navigation controls. In other words, the infrastructure of a modern application. The pack comprises ExpressBars, ExpressNavBar, the layout manager and the skinning library. The first year price is $599.99; subsequent years are $239.99 annually.

    Upgrade paths

    Now for the upgrade paths. Traditionally, as you know, we’ve sold individual Suites on an upgrade basis. From v2011.1, we will no longer do so: the only way of getting the VCL controls is through purchasing one of the packs. So we considered how are we going to help and encourage people to move to this new world in the fairest manner possible.

    The first point we decided on is to provide a 12 month “amnesty” period to allow you to upgrade the Suite you own to v2011.1 without having to purchase a subscription immediately. This gives you the ability to get the latest code and still have time to evaluate which pack to upgrade to and to budget for it. I will emphasize that, in 12 months’ time, the only way to get updates and upgrades is to switch to a subscription pack.

    The Suites that fall under this amnesty plan are:

    • The ExpressBars Suite ($79.99/$59.99)
    • The ExpressQuantumGrid Suite ($199.99/$179.99)
    • The ExpressPivotGrid Suite ($131.99)
    • The ExpressLayout Control ($99.99)

    The double prices shown are the upgrade prices with/without source for the current major version; single upgrade prices indicate the product is only available with source, again for the current major version. These upgrade prices will be offered for 60 days from the day of release of v2011.1. After that, they will no longer be available.

    If you have an older version than the current major version, the upgrade prices change. For one version earlier than the current major version, the upgrade price is 70% of the current product price; for two versions old, the upgrade is 85% of the current product price. Anything older than that, there is no upgrade path.

    An extra bonus is that we shall be bundling the new version of ExpressPrinting System for free if you’ve previously purchased it..

    Promoting to a subscription pack

    In our efforts to be fair about the costs of promoting your licenses to a subscription pack, this is where it gets complicated. We recognize that there is no “one price fits all” solution to this—and indeed such a solution will be unfair to many customers—so we’re going to have to do this on a case-by-case basis. The calculation we shall apply will be this one:

    Pack priceCost of Licenses already purchased + Cost of upgrades

    Or, since the cost of upgrades is pegged at 40% of the original price (except as noted above), we’ll use:

    Pack price60% * Cost of Licenses already purchased

    Let’s illustrate:

    1. Suppose you just own a license to ExpressBars. You decide that the closest pack you can promote to is ExpressNavigationPack. The calculation we’ll do is:

    $599.99 (cost of pack) – $199.99 (cost of ExpressBars as individual product) + $79.99 (upgrade cost for ExpressBars) = $479.99 

    2. You want your licenses to be promoted to ExpressNavigationPack. You already own Bars, Layout, and Skins, but not NavBar. Your price will be:

    $599.99 – 0.6 * ($199.99 (Bars) + $249.99 (Layout) + $199.99 (Skins)) = $210.00

    If you have any questions about the cost in your particular case, our client services department will be glad to help.

    Warnings – Danger, Will Robinson!

    The new subscription installer will not contain any previous versions of our VCL products. The old product versions cannot be installed and used alongside with the new subscription versions. Remember that one of the overriding goals of the new subscription plans is to update everything at the same time, and to avoid the incompatibilities and support issues of running an older version of X with the latest version of Y.

    A couple of examples will illustrate the problem:

    1. You own ExpressQuantumGrid Suite v6 (or earlier) and ExpressBars Suite v6 (or earlier) and you want to upgrade only the grid to ExpressQuantumPack or ExpressGridPack. The ExpressBars Suite version you have will be unavailable for installation in the new subscription installer. Moreover, the new installer will remove the current ExpressBars Suite installation because it is incompatible with the new subscription version (v2011.1).

    2. The same background – you own ExpressQuantumGrid Suite v6 (or earlier) and ExpressBars Suite v6 (or earlier) and you want to upgrade only the bars to ExpressNavigationPack. Likewise, the installer will remove the installed ExpressQuantumGrid Suite due to version incompatibilities.

    So, you need to carefully consider your upgrade options and select the packs that include all the products you want to work with.

    Timetable

    The VCL team are ready to publish v2011.1; the final install is complete. The web site has been changed to reflect this new information and is being proofread and final edits are being applied. The sales system is being updated with the new pricing and promotion calculations.

    We will release this week.

  • Conferences vs. codecamps? Is it binary? (Message from the CTO, newsletter 48)

    While at Tech·Ed in Atlanta, Jeff and I recorded a specially-themed Message from the CTO about conferences and the like.

    Conferences or codecamps? Is it binary?

    For a change, Jeff and I have moved out of the studio to our booth at TechEd in Atlanta to record this particular Message from the CTO. As we're here, what better topic than a discussion about big conferences versus little codecamps.

    Over the past couple of years, there has been a marked increase in the number of programmer codecamps being produced. You can understand why: many of them are free or low-cost compared to the $1000 entry cost or so of the big conferences. And they're usually right next door, they have the same speakers, and they attract local recruiters. You have some great opportunities for one-on-one networking with peers and with vendors.

    That's not to say that big conferences are all negative. The gathering of a large number of attendees is a great opportunity for big splashes: the new product, the shift in direction, the big names. Just think of conferences like PDC, JSConf, Google IO. These days even stay-at-homes can benefit: the videos of the keynotes and talks are broadcast immediately or are made available quickly. For the attendees, there's usually a big attendee party at places like Universal Studios to relax after sipping from the firehose.

    For vendors like ourselves, the issues are magnified. We have a certain pool of money for marketing and advertising. Do we spread it out? Concentrate on doing more smaller events, or a couple of larger ones? Doing smaller ones involves more travel: we have to send our evangelists out to more places, so there's more flights, more hotels overall. Doing larger ones means more logistics: there's the booth design and transportation, more swag to produce, and more people to send.

    So, what do you think? Do you like the big official shows or do you prefer the intimacy of small codecamps? Let us know.

    Thanks must go to our Community Evangelist, Rachel Hawley, for providing me some of the better ideas I put into the post. The rest of them are mine, alas.

    You can view the video here.

    (Aside: it was a hoot to record. Amanda was standing right next to the camera holding up my laptop, which was acting as my teleprompter. Unfortunately my “distance” glasses had broken earlier that week and I had on my “computer reading” glasses instead: I was finding it difficult to read my own words on the screen. Hence. The. Almost. Shatneresque. Delivery.)

    Anyway: what do you think? Do you prefer big conferences? Or the smaller local codecamps and user group meetups?

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