This Blog


Favorite Posts


August 2008 - Posts

  • WinForms Charting basics: Taking Stock

    In this episode of the video series on the various chart types available in XtraCharts, DevExpress' charts product for WinForms and ASP.NET, we look at the stock chart, that most basic of financial charts.

    The stock chart is fascinating in that it embodies four values per argument point instead of the usual one. The argument axis is the trading date and the value axis the price of the stock being plotted. The four values are open, close, high, low and the point is represented as a vertical line with tick marks rather than a single dot.

    For this demo I copied a month's worth of stock prices for MSFT from Yahoo Finance and inserted them into a new Access database.


    [Sidebar note: This video almost didn't get made. I had a plane to catch, Jeff was ready with the camera, we started shooting. I was recording with Camtasia on my little Dell notebook. Half way through, it overheated and ground to a stop. I had to put it in the freezer compartment of the office fridge to cool it off. Minutes ticked by. Finally it was cold enough to do the recording and this is the video that came out of it. One take, no messing. I then popped the notebook back in the freezer so that the rendering would complete without overheating. Needless to say I caught the flight, and I now have a new notebook, one with a better cooling system.]

  • WinForms Charting basics: the Gantt Rant

    It's certainly turning into a charting marathon in my blog recently, and why not? XtraCharts is just so cool.

    Anyway, Jeff has completed the editing of the next video in my series on the various chart types in XtraCharts, and so I present it without further ado: the Gantt chart.


    [To make customers in Europe happy, I'm using D/M/Y formatted dates. Well, OK, that's just how I have it set up on my machine, but it does show you that our controls work perfectly well with a non-US date format!]

  • WinForms Charts: How to use panes programmatically

    A request came in just recently, prompted by my video introducing the three major new features in XtraCharts v2008 vol 2: how do you set up a couple of series and display them in separate panes. "Programmatically" came the kicker before I could quip with "watch the video properly."

    So our Charts team quickly whipped up a couple of examples and have uploaded them to CodeCentral.

    The first shows the steps needed for the example I showed at design-time in the video. Here we bind to the gsp.mdb database and display the chart using the automatic SeriesTemplate property. We show each of the 5 series in the data in a separate pane.

    The second shows the same data, but this time the series are explicitly set up. (For brevity we only show two of the possible 5 series in the data. It left as an exercise for the reader to display the other 3 series Wink.)

  • WinForms Charting basics: the Radar plot

    A quick video this one, part of a series on the different chart types available in XtraCharts. Here I discuss the three radar charts provided in our charting product: radar points, lines, and area.


    [For some reason, it looks as if some demented two-year-old got hold of my mouse during this one; since it was me, I'm going to say my coffee must have been a tad strong that morning. Just a tad.]

  • DevExpress VCL products: Support for Tiburón

    Today Embarcadero announced Delphi 2009 and C++Builder 2009, previously codenamed Tiburón.

    Consequently, we have been getting some questions on what our policy is about supporting these new compilers with our VCL products. To which, I can only say, duh, support them, of course.

    However, there is more to this support than meets the eye, so let me expound a little on the subject.

    The biggest change, at least as far as we're concerned, is the new support for Unicode in Delphi 2009. I really don't want to go into the issues too deeply here, but will instead state that the Unicode support is pervasive. The default string type is now Unicode and not Ansi as before. Although CodeGear have done a remarkable job in making the porting of normal application code to Delphi 2009 as seamless as possible, it is not the same with some of the code we have in our codebase. As a quick example, in order to gain the best performance for our VCL UI Ocontrols, we make extensive use of direct Win32 API calls. Of course, in doing so we've been making use of the Ansi versions of the interfaces. All of these need to be changed, thoroughly checked and tested after conversion. And that's just the tip of the iceberg: we can't just make wholesale changes to our codebase, since we need to have it support all Delphi versions from Delphi 6 to Delphi 2009 (and, no, just $IFDEFing whole blocks of code doesn't count).

    The next biggest change is the interface between C++Builder 2009 and Delphi 2009. Again, there are a great many changes in this area. Huge. Although the vast majority of our VCL customers use Delphi, we have to make sure our C++Builder customers are well served by our port. I'd have to say I wish Borland of old had spent as much quality time in this area as Tiburón R&D have: our C++Builder support would have been much easier.

    The current goal for Tiburón support is to convert all current versions of our active VCL products. Let me parse that more carefully.

    • By "active VCL products" I mean all of the VCL suites and libraries that form part of our VCL subscription and that are mentioned here. The retired products that you may also download as part of your VCL subscription (such as CodeRush for Delphi, say) are not included and will not be ported. Other products that form part of the unified installer, but that were not supported in Delphi 2007, are not included either.
    • By "current versions" I mean only the latest version of a particular suite will be ported. So, for example, only ExpressQuantumGrid Suite v6 will be converted, only ExpressPivotGrid Suite v2 will be ported, and so on.

    The next big change is the new generics support in Delphi 2009. We are not planning on supporting generics with the current conversion project.

    Although Embarcadero announced Delphi 2009 and C++Builder 2009 today, they explicitly refrained from saying anything about when they would be shipped. Considering the vast number of changes and their architectural breadth embodied in these new compilers, there is absolutely no possible way for us to be ready with our support on the day that Delphi 2009 and C++Builder 2009 are released. None whatsoever. We shall require a good deal of time to test our code with the final RTM of the compilers, once we get it.

    Given the fundamental changes that are needed in our code to support Tiburón, we are considering having a beta program so that customers can get the code early and do their own testing. It's likely that this will be offered to our VCL subscription customers initially.

    Oh, and if you own one of the products being updated, the support for Tiburón will be provided for free. Obviously it will be part of the normal VCL subscription update cycle as well. It goes without saying that if you are planning to move to Delphi 2009 or C++Builder 2009, I would urge you to make sure that you have the latest versions of the products you own and that you've fully integrated them into your applications. Moving existing projects to Tiburón is going to be enough work without having to worry about the fact that you're upgrading your controls as well.

  • WinForms charting basics with XtraCharts

    Last week, Jeff and I recorded a "basics" video about XtraCharts.

    In looking at this video, I see I should do further explanatory posts explaining the glossary or nomenclature that XtraCharts uses. At least I touched on things like arguments and values, but skirted over series. There will be more!


    I'd have to say that Jeff's skill at editing out the "erm"s and so on makes me look better than I really am (in other words, be thankful you're not actually there during the recording Smile).

  • WinForms & ASP.NET Charts: what's new in v2008 vol 2

    Here's a video that describes three of the important new features in XtraCharts for v2008 vol 2.


    The three features I talk about are:

    • Intelligent label layouts: making sure that your series labels don't overlap. Since this can be a very processing intensive operation when there are many labels, this is enabled as an option.
    • Trend lines in financial charts: the first in a series of new indicators for financial charts (others will be added in future major versions of the product).
    • Multiple panes in the chart diagram. This feature is helpful if you don't want to overlay one chart on top of another.

    (Looking at the image above, it seems as if I've totally embraced extreme shoulder pads in some show of solidarity with a bad TV science fiction series. I can assure you that you're seeing the chair I'm sitting on Smile)

  • WinForms and ASP.NET Reports and exporting to PDF

    Recently an issue came up with regard to the export to PDF functionality in our printing and reporting suites, XtraPrinting and XtraReports. The issue was in regard to the use of characters that weren't the normal 7-bit ASCII characters and whether the fonts should be embedded or not in that case.

    I decided to take a peek at how we've implemented the export to PDF functionality in order that you can gain a better understanding of the issues. Since the whole subject is pretty complicated, I took the hit so that you didn't have to Smile.

    With PDF, there is a fundamental distinction between the notion of a character and a glyph. A character is a symbol, like "A" or "4", whereas a glyph is an image or rendering of that character. A collection of glyphs is known as a font.

    Easy enough, except that a character has to be encoded in some way into a binary number. We're used to thinking of the character "A", for example, as being encoded as 0x41. This particular encoding started life in ASCII and has now propagated into Unicode.

    That's all very well, but in the days when a character was encoded in a byte value, there weren't enough bit values available to encode all possible characters. So the notion of codepages evolved to encode different characters in the range 128 to 255. In the Latin codepage or character set (sometimes known as Latin-1 or Windows 1252), for example, the character à is encoded as 0xE0 (and, again, that propagated to Unicode). However, on the Mac the character à is encoded as 0x88.

    Back to PDF. PDF is a file format that is essentially text and not binary. (Yes, I'm oversimplifying since text blocks can be compressed using the Deflate algorithm and will appear as binary blobs, but bear with me.) The text is obviously represented using some encoding. There are a set of standard encodings for text in PDFs: one for Macs called MacRomanEncoding, one for "Windows ANSI" (which is essentially codepage 1252) called WinAnsiEncoding, and one for a more general PDF codepage called PDFDocEncoding. All of these encodings are single byte encodings: each byte value represents a different character.

    Back to fonts in PDFs (as you can see, there are lots of strands to pull together here to get the full tapestry). There are two different ways to define the fonts in a PDF. The first, and very lightweight way, is to describe the font as a set of metrics (name, width of glyphs, slope of italics, and so on). The reader of the PDF (say, Acrobat Reader) is then responsible for locating the font on the user's machine and using it. If the actual font is not available on the user's machine, the reader then has to locate the nearest font that matches the font metrics embedded in the PDF.

    If the PDF uses fonts in this way, the text in the PDF is encoded as one of the standard encodings. As you can imagine, you are relying on the user machine being pretty similar to the machine that generates the PDF, otherwise the user is possibly going to get some weird effects (wrong or missing glyphs, a different look to the page, and so on).

    In XtraPrinting and XtraReports, we used to use PDFDocEncoding in this situation. However, the majority of our customers use the Latin-1 codepage, and so there was a possibility that reports could have some missing or invalid glyphs when exported as a PDF for these customers. For the next minor version (2008.2.3), we've switched to WinAnsiEncoding and this change should help more people.

    Of course, you may be thinking that it's nice to generate very small PDFs in this way, but it's all a little bit too hit and miss on the reader side. That's why there is a second way of defining fonts in PDFs: to embed them.

    Here the onus is on the writer of the PDF. It has to analyze the text in the PDF, work out which glyphs of the font are being used and then embed those glyphs directly in the PDF. If fonts are embedded in the PDF in this way, the text is actually encoded in a two-byte manner and a map is generated that maps the character encoding to the index of the glyph in the embedded font.

    Using fonts in this way, you get absolute precision control. What You See (as the writer) Is What You Get (as the reader). There is no wishy-washy, crossed-fingers, hope-for-the-best aspect to reading the PDF: the end-user will see exactly what you wanted them to see, no dropped or swapped glyphs. The downside to this is, obviously, the PDF is "heavier" or larger since it has to have all those glyphs embedded.

    (Note to those who are really clued up on PDFs and character encodings and font support. There is yet another method: the writer can define a ToUnicode character map, or CMap, that is a single-byte encoding that uses a special map to work out which glyph to use with a font that's not embedded. We don't support this variant yet.)

    Having said all that, you can mix and match. You can have some text in your PDF where you assume that the reader will have the required fonts available to display it, and you can have some text where you embed the fonts. In our printing suites, you can manage this scenario by using the NeverEmbeddedFonts property. If you name a font in the NeverEmbeddedFonts property (it's a semicolon-separated list of font names) it will be defined in the PDF in the first, lightweight, way. If a font is used in the PDF that is not in this list, then it will be embedded in the PDF in the second, heavier, way.

    And that's pretty much it. I hope that this exposition has made the whole issue of fonts in PDFs clearer and that it helps you make the best decisions in your particular scenario when you need to export your report to PDF for your users.

  • Installing Visual Studio SP1 wiped out my item templates

    Sounds like a conspiracy theory, so maybe I should put it all in caps, with spelling mistakes: INSTALING VISHUL STUDIO SP1 NUKKED MY DX NEW ITEMS IKONS. KTHXBYE.

    A customer phoned me up this afternoon saying that he'd just installed DXperience Enterprise but couldn't find any XtraReports items in his toolbox. He was worried in case the install had failed in some way. Ha, I thought, I'll just walk him through creating a new application that has a report, and show that the XtraReports controls only show up in the toolbox if the designer is showing a report form. You know, that friendly CTO helping the customer thing.

    So we started off together. Create a new solution, I said, and we did. OK, to add a report to this project, I said, we right-click and select New Item, and select XtraReports... WHERE THE HECK HAVE ALL MY ITEMS GONE?

    For some unfathomable reason, installing SP1 had wiped all third-party item templates from this list. It was bare. No XAF, no XPO, no XtraReports, nothing. A tiny little tab still promised some DXCore items, but otherwise zip, nada, zilch. I shivered.

    Meanwhile, I'm sure my customer was slowly backing away from the phone: the CTO of DevExpress doesn't know how to create a simple XtraReports app? What the... I made some reassuring noises -- OK, maybe they were just noises -- and we finished the call with my abject apologies.

    I had a look at my other machine which I use for travel. There I'd installed SP1 and DXperience 2008.2.2 (I was late in updating it on that machine) in that order, and, lo, the new items page was full.

    So there was nothing for it but to uninstall XAF and DXperience and then reinstall them (hmm, now I write this perhaps Repair might have done the job in a shorter time) and full functionality was restored. So, if you run into this, you'll know what to do.

    Meanwhile, if you did call me this afternoon about XtraReports, I can lead you though the basics over the phone now. Honest Smile.

  • Windows 7 news starts filtering out

    Microsoft Senior VPs Steve Sinofsky and Jon DeVaan (the former in charge of Windows and Windows Live and the latter in charge of Windows Core Operating Systems) have started a new joint blog called Engineering Windows 7 to talk about, well, Windows 7, the next version of Windows beyond Vista. So that would be Lost Horizon then (bada boom bada bing Smile).

    They're going to be regularly blogging about the new things in Windows 7 all the way up to PDC (Professional Developers Conference)in October -- where already there's a large number of sessions booked to talk about Windows 7 -- and WinHEC (Windows Hardware Engineering Conference) the week after. It seems that, after a virtual desert from the past couple of years, we're going to be deluged with information until we're drowning in the stuff.

    The blog is bound to be interesting. My recommendation then is to subscribe to the RSS feed so you're kept up to date with what they say. (Well, as soon as it's ready; must be a Windows Live thing.)

    (Er, Ray? I know that we're a Platinum Sponsor of PDC this year and that we have a large booth 'n' all and it's likely to be a madhouse in the Exhibitor's Hall, but could I have lots of time off to go to these sessions? Ray? Don't walk away laughing hysterically, I'm asking a serious question. No, don't switch the light off...)


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