Page Bottom  Documentation

Davin's Phoenix Grid

First, we've already got the main calculation engine that accepts/produces several matrices of numbers, which we keep in a bunch of global variables in the workspace. I'd like to reduce that (in the GUI area) to a single global with a nested vector of those matrices. Then, instead of referencing each matrix by name, it references them by their subscript-position in the vector. That number, combined with a row and column value, can then pinpoint any piece of data in the system. (We can continue to use names if we'd rather, which is used to look up the subscript #, at a relatively small cost in speed, space, and complexity.)

Second, the grid-screens will be soft-coded and created on demand from a "grid definition array" (which can be stored in application configuration file(s)). This array has in it a list of every piece of data to be shown in the grid, either as a constant or by referring to a piece of data in the master data vector with 3 numbers (array, row, column). All data to be displayed (except constants) should be pre-calculated and stored somewhere in this vector of matrices so it can be referenced in this fashion. The grid data will be populated by simply extracting the data items and placing them on the grid. Input data may be accepted from the grid and used to update the array. Also in this grid definition array are GUI definitions that are used to define the non-content portion of the grid. This would likely be structured in a []WI{each} format and simply applied to the grid when it is first defined. If needed, we can also reserve space in this array for custom functions/expressions to run when the grid is changed so that special effects can be dynamically applied, such as turning negative numbers red.

Third, any changes to the master data array will send a signal to all active grids informing them of which piece(s) of data have been changed. The grids will then update that single piece of data if they find it present within themselves. When the main calculation engine runs (and changes almost everything), it will send a "global update" signal to all grids telling them to redisplay themselves with all new data.

Fourth, we have a report printing facility using NewLeaf which does provide a very attractive and fast preview feature. Reports are "views" of the data, just as grids are. There are a set of standard reports that are sufficient for any project, but it is expected that most users will prefer to use a consolidated/integrated format that is more to their liking (e.g. FHFC). The new grid object has a print facility. Perhaps it is sufficient for the special formats, or at least the first attempt at them. In the long run, anything should be possible, even an interface to Crystal Reports.

Fifth, if we're pre-building our grids, then we'll want to separate these PVP's into two lists each: (1) for things that are static and can be easily predefined for the grid, and (2) for things that might be varying at run-time based on data or user selections. The more stuff we can get in category 1, the faster the application will perform.

Davin, is there anything in the following to clarify or integrate above, or should I toss what remains? Should we provide a GUI interface for it as well? Or are we *only* talking about printing what's showing in the grid (and never anything else)? I was thinking about designing a "Print Preview" kind of view (probably one for each different report) that generates an on-screen display of what'll come out of the printer (if its not identical to an existing grid). But that is a little more complicated to handle in the screen definitions and such. OTOH, if we design the system with the more complicated definition structure, we'll be able to expand it to do fancier things later and in other projects.

The following files are our development files for Phoenix. Carl did maintain this list by keeping them on his old desktop computer (til 2006/04/09) and occasionally testing to see that they are all that is needed. The laptop has apl2000 version 4.0.01.

horizontal line
to home page e-mail Page Top