Details

Yes, some details are missing. (Gasp, another list !!)

• Where does this program come from that uses the API?
  • If you have the skills you need to write it, go for it. If you do not have the skills, get someone else to do it.
    Nebula Research and Development can do this with you or for you.
• What if you’re generating the images in Linux or AIX, etc?
  How do you get HTML or images to the Windows web server?
  • If you’re using *nix then you can use jGraph or other Java components to save images on the *nix DBMS server.
  • When HTML or image files are generated, you can use Samba to pass them to the web server, or you can use a script and FTP them.
• How do you execute code that might reach into your MV environment or local OS data files to get the data?
  mv.NET has a trigger feature where an update on the DBMS server will cause action in the client. So as an example of how this might work:
  • You have an mv.NET program on the web server monitoring your GRAPHS file in your MV account.
  • When a user requests an image, maybe in your After Display or Validate event handler, you generate data and write it to this GRAPHS file.
  • mv.NET sees the data, reads it, populates a new graph object using whatever too you’ve chosen, writes the HTML or image to a local file, deletes the item from GRAPHS, then goes back into wait mode.
  • Your BASIC code waits in a small loop, periodically checking the GRAPHS file. When you hit a READ/ELSE clause, you know the graph has been generated and the trigger has been deleted, so you return back to your user, setting the name of an image or maybe the filename for an IFRAME.
  • With UO, UO.NET, etc a similar method for server polling would be coded manually, but this is fairly easy to do.

Create your own API to "front-end" a component

I suggest you do whatever you can to minimize any component-specific code which it might be convenient to put into your application code. As an example, there’s nothing in the DesignBais API for using the OWC that actually mentions the OWC - the OUTPUT.zz variables can be used with any server-side component. (Granted the attributes defined are specific to the features supported in the OWC but at least they called the variables OUTPUT.zz instead of OWC.zz.

In your own callable API you’d define some variables just like the OUTPUT.zz variables in DesignBais, but instead of setting the PROCESS.TYPE and PROCESS.REFRESH variables, you’d call to a program, something like:
    CALL ZEDGRAPH( FILENAME, RESULT ) or
    CALL JGRAPH( FILENAME, RESULT )

Rather than creating something completely new, you could just use the exact same DB variables but change their use to suit your purposes. Any developer using DesignBais in your environment would know that these are the only variables for graphing regardless of which component is used. As above, call to your API / Subroutine which would include the DBI.COMMON, so the OUTPUT.zz variables would be available to your code just like it is to the DB API for OWC. The only thing the routines need are a custom FILENAME, and some variable to pass back an error message or other return codes. The subroutines would handle the underlying operations of reformatting the DB variables for the specific component, generating the graph, getting it to the web server, and if all goes well they’ll just return with an OK message. If you do use the DB variables for your own purposes, it would be advisable to wipe them out after you generate your image.

This technique hides the underlying implementation from the BASIC application developer. Another article on Getting Client Info discusses a specific application which would do well to make use of this technique.

Relative merits of the OWC

OK, that’s how you would use alternate components to create graphs and charts. Why not just use OWC as documented with DesignBais? (Gratuitous and unncessary list follows )

• DesignBais uses OWC on the server to create images, but then it renders those images in a Graph field on a form. But that means no interaction with the graph is possible – no events can (yet) be fired from a DB graph, not even an Image event. Yes, some people like to click on interactive charts, maybe to drill down into detail, sort them differently, etc.
  • With the information in this article you’ll be able to create graph images on the server which are then rendered as DB Images, and that will provide a tiny bit of interactivity.
  • This isn’t a major issue; you don’t need to have a user click on a graph directly to provide interactivity, you can provide buttons (even image buttons that look like they’re a part of the graph) that allow the user to zoom, rotate, change colors, drill down, etc.
• More commonly, you may find that you want a little something more, or different, from a graph. As an example, OWC supports spreadsheet functions and pivot tables, but the DB interface doesn’t provide access to that complex client-side functionality. We can get DesignBais to simulate functionality like a pivot table with On Form Reports but it takes a good deal of BASIC coding. Other features not supported might be image backgrounds rather than solid colors, using something other than bars that get stretched out to show progress, adding text to the image other than the labels and title. The point is, if you find limitations in OWC, at least now you have info on how to get around them.

You might want to use OWC in a client mode (outside of the supported DB context) to provide more interactivity. This should be possible using the info I provided for Client-side scripting in DesignBais. But, since OWC is an ActiveX control (as are many of the other client-side alternatives), it can only be used with Internet Explorer. If you want an interactive graph in W3C mode you’ll need to use something else. Remember, I’m not saying we can’t use OWC in W3C mode through DB, because DB renders pure images and does not put anything else into the client.

There are many resources available if you want to use the OWC yourself for client or server-side development, in particular on this MSDN page for Office development, click on the link for "Office Web Components". If you choose to use the OWC outside of the standard DB context, be aware that there are licensing rules which must be observed, especially if deploying the OWC to client browsers.

On the other hand one reason to not use OWC is that Microsoft will eventually stop supporting it, but for our purposes we will still be able to use it for many years to come.

More than just a tool for DesignBais

Once you start using graph components for DesignBais, someone is probably going to ask if you can use them for your non-DB printed reports, send them in emails, etc. The answer is an emphatic yes. Once a graph is generated into an image file it can be incorporated into any document that renders images: HTML webpages or email, word documents, even PDFs. If you use the OWC or other components to generate charts for your DesignBais web forms, there’s no reason not to use that exact same code to generate graphs in other parts of your application.

And finally, to pre-empt the next question that might come up "can we put this data into Excel?" : Sure you can. You can even use Excel to generate your charts and graphs. In fact I wrote a product several years ago that generated real Excel documents from BASIC, including charts and graphs, just like we’ve seen here in this article. NebulAnalysis is no longer offered as a product but we can talk about doing these sorts of things in your application. Let me know if you’d like to see an audio/video presentation of how it worked.

Have fun ! And please let me know if you use the information provided here to come up with something neat !

In an upcoming article I’ll discuss the benefits of using constants in DesignBais. Tables will include constant names for graph types (did you know there are really over 60 graph types and not just those documented in the DesignBais reference manual?), and dialogs (types, buttons, return values). I’ll also touch on how Equates should and shouldn’t be used from the Field Properties form and in code.