DesignBais Tip – Alternative Graphs

The Graph component in DesignBais is great. The documentation might make the BASIC code for graphs look complex, but after you do it just once, you’ll realize it’s quite simple. This article discusses how to generate graphs using alternative components. As a bonus we’ll see how DesignBais can be integrated with lots of third-party products and services, to provide functionality for your users far beyond what’s “in the box”.

First, let’s break down exactly what the graph component in DesignBais is. It’s a third-party server-side component with an Application Program Interface (API). Like DesignBais, it has its own variables that can be set, and various subroutines (functions or “methods”) which can be called, it then draws an image that is sent to the browser. How well any component does that task is up to the component developers. DesignBais International elected to use the Microsoft Office Web Control, so we can make use of whatever is in there. The API for the OWC corresponds to the DB Reference manual: You set a title and its properties, X and Y axis data, you plug in your numbers, then tell it to render.

Why should we use OWC through the DesignBais interface? One reason is because DBI made it easy for us to do so, so why not? Above all else, DesignBais facilitates the creation of fairly complex and highly interactive web applications without the author having to know anything about the internal plumbing. This is just another example of that. If you are happy with the graphing capabilities in DesignBais, look no further for alternatives, what’s in there will satisfy about 95% of the developer and user audience.

Also, at the moment it’s the only graphing component that DesignBais natively supports, but the OWC isn’t the only component that can be used like this. As we see below, there are many similar components in the market, some for fee, some for free, some open source. The trade off is that for alternative functionality we will need to do our own coding of the “plumbing” that gets MV data into some other component and then out to the browser. After we discuss how to use other components in this way, we’ll come back to discuss the relative merits of using the OWC – with or without the DesignBais-specific interface.

Assuming we have needs beyond the provided OWC functionality, the objectives are:

  1. Find another component.
  2. Identify the API.
  3. Get settings and data from BASIC to the component through the API.
  4. Get the resulting graph into a DesignBais web page.

Finding components

For DesignBais v1.1, long before the Graph component was even added, I wrote my own primitive graph generator. Rather than using a third-party component I did it the hard way by drawing boxes and lines, adding color at specific coordinates, manually positioning text, etc. Sometimes I can be such a numbnut. I highly recommend you take advantage of someone else’s focused effort in this area, even if it costs a little.

You can use Google or other search engines, or find component brokers for commercial graph and charting components. There are a ton of them out there.Here are some of the main offerings:

  • ZedGraph – free, open source, highly capable
  • NPlot – free, open source, used in commercial code but not well maintained anymore
  • jGraph – free visualization tools for Java developers
  • .netCharting – see their guages, dials, and maps too
  • Data Dynamics – see their SharpGraph product as well as DynamiCube and others
  • DeveloperExpress – see xtraChart
  • Syncfusion – EssentialChart
  • Dundas – charts, guages, diagrams, etc
  • Modulus FE – StockChartX is “a component designed BY traders, FOR traders”

Don’t get sticker shocked by high costs for some components. Just look at what they do, decide if you need that functionality, and compare the cost and features with other offerings. Also be sure to check whether the cost is per-server, per developer, etc. Don’t assume that free and/or Open Source means less functionality than commercial-ware, or that the components are inherently better or worse than commercial offerings.

It may not matter if you get a component that was created for thick vs thin client development – if all you’re doing is generating an image it doesn’t matter how you create it or where that image goes. We’ll get to this soon.

4 thoughts on “DesignBais Tip – Alternative Graphs

    • Interesting!
      I’m looking forward to seeing how I can use third party tools with DesignBais. I have previously wriiten .net apps using such tools – Dundas Charts and Telerik Controls – to provide graphically rich business information systems. I started out with OWC, but quickly move on from that because of the need for interactivity. There is also the requirement to have OWC installed on the server, and an Office licence to be consumed. Not normally an issue, but I’d guess the take-up of products like OpenOffice might be slightly higher than the norm in the, er, "financially astute" multivalue community.
      I’m hoping the experience with DesignBais isn’t going to be much more difficult than dropping a third party control onto a form in VS and setting a few properties in the aspx code behind page to hook the control up to an generated dataset. If its messy to do that ,and your app has a lot of charts rather than transactional data ,then you probably wouldn’t be using DesignBais. Horses for courses.

    • Phil, thanks for taking the time to comment. I understand everything you’re saying. I’ll write a small follow-up to this article soon regarding OWC licensing and possible errors which might compel someone to consider the alternatives discussed here.

      Running in an IFrame to an ASP.NET component can give us that interactive experience, but the DB form won’t be interactive with that chart without some diligent effort. It’s cool to have the chart right within the page, but it might be more elegant from a coding perspective to just launch a separate ASPX page, let the user do what they need interactively, save some state on the server via mv.NET or otherwise, and then have DB read that state back in a modal return event when the user closes their popup form.

      DesignBais is sort of intended to be a complete solution for people who don’t want the bells and whistles available in ASP.NET – or the related hassles. I think my ongoing message here is that there are those of us who appreciate DesignBais for what it is but we still want some of those extras – and I’m trying to show people how to get the best of both worlds. This turns the "either / or" and "horses for courses" position into a "best tools for the job" position, where DesignBais fits right in with whatever else we need to create the environment we want.

    • Tony
      I think we’re singing from the same hymn sheet here. I’m not that far down the road of working out what I can and can’t do with DesignBais (but I am intending to learn fast!), but I’ve been around long enough to know that there is ALWAYS a trade off between functionality and ease of use/speed of development, and also that these days developments (and web developments in particular) call for a mix of technologies. You can’t be too precious about any particular tool, you just have to be aware of the tools available and pick the best one for the job at hand. Now if one "swiss army knife" tool can get 80% of the job done, great.
      I see a parallel with the situation a couple of decades ago with Reality, where A*L*L was available as a 4GL. It was great at what it was good at, and you could rattle out apps if you knew how to use it, but for some things you just had to go back to DataBasic to get the job done. I’m hoping DesignBais will fill a similar role now, supplemented by etc for the complex, awkward or just plain flashy stuff.
      I’m starting to see what you mean by the comments made about getting excited about programming again.

    • People interested in this charting for DesignBais blog may also be interested in some new work that I’ve been doing:
      (So far there are Parts 1 and 2 of that “series”)

Leave a Reply