In SYSDICT there are a symbolics like COUNT, SIZE, etc. The idea being that these can be universally used in RLIST.

How do you add these to Reports using REPORT BUILDER? The column selector won't allow you to type in columns not listed from the active dictionary and you cannot use multiple tables outside of xlate symbolics.

Report builder doews not support this at this time but run_report will. You should add this to the enhancement requests for now.

Is there any way to override the fonts used by Run_report?

Follow each field with the word COLFONT followed by font structure.

Structure is font structure in OIPI FONTS with each parameter seperated by "|,".

Ex. Listing fld1 in books using courier font and 24 pt size.

  LIST BOOKS FLD1 COLFONT COURIER|,12

               OR

use FONT followed by font structure to use for all columns.

Great.

Another question - is there a way to use the ?EnterParam? syntax in a select statement using rlist() or to get run_report to properly parse a complex select statement that uses parentheses? Reports that AREV ran now break due to these two being used. For example:

LIST filename WITH YEAR=?year? AND (WITH F1=val1" OR WITH F2=val2") TOTAL COUNT DET-SUPP

The above won't run in run_report due to the () in the select portion, but moving the question to a SELECT statement ahead of the run_report call doesn't work either (nothing selected, never asked for the year). Given a preference on which one should work, I'd pick fixing run_report to support nested arguments in the select part of the command - the above can't be fixed by repeating the "year= part of the command without asking the user again for input (not acceptable) or just re-writing the whole thing (in which case I'd probably do something entirely different and get results closer to what the old COUNT command did, for this particular sentence – but other complex selects are sometimes more troublesome to redo, although repeated select calls do work, that requires programming). I haven't looked to see if using the report builder would allow a complex select, as it won't allow using COUNT as a field name (which would solve this one command's problem).

Also,

Can you override the "default font" for all columns and all reports in any way, or is it hard-coded into OI?

Sometimes it is a good idea to abandon AREV concepts and take advantage of OI's superior interface design. The in-line prompting with "?text?" is a case in point. In OI, I wrote a one-step report execution interface which allows data-defined reports with multi-command selection and execution statements and token-based user input substitution with input validation, etc. One of my motivations for this project was the need to replace the in-line prompting, of course.

It's not something I use often - but in this case, a program will have to be written to ask the user for a Year (a number, 4 digits) or a window created just to get that info (kind of waste of developer resources, for a once a year rpt - kind of like building a window everytime you just need a msg to get some user input). If it were something anything else much in the app ever asked for, I'd have a window that asked for a year entry and the report shell could handle it - but this particular 'report' counts W2's and is run once a year to make it easier to order forms. The report shell, has been happily functioning for over 10 years with no knowledge of how it selects records for each report, as it is all call driven - using query windows for the selects or collector windows to build a select statement in AREV and is working just as well in OI using similar methods, but no query interface (still a big loss in OI vs. the "old-dumb DOS pgm"). And it is well documented so that users could add their own reports (to menus in AREV, to the report calling window in OI) using the app's built-in collector windows and copy of the dict for the table they have built reports for.

The bigger concern, tho, is the lack of ability to have nested selects in any report. This isn't an AREV concept and is one that should be supported as a basic function of the report language. Whether the report builder might allow it isn't of any relevance, since the report builder is unable to just count rows and do nothing else (at from what I can tell - no COUNT field allowed, or any other special fields such as COUNT, which do work in the list statement itself if passed into run_report).

So, in this case, the AREV concept works just fine (asking the user for input in the LIST statement), but the basic concept of nested selects (supported by any database I've ever seen since about the mid-80's), doesn't work at all.

Now, in this one case, the LIST statement (or the call to the report) could have the year hard coded into it and I could then spend time doing updates to customers every year, in anticipation of when they'll need to count each year's W2's, but I'd prefer not to do so (and I know some people run it for prior years, to get an idea of how their employee base has changed over the years).

I have used nested selects for years in AREV and OI. Admittedly EasyWriter in AREV did not directly support nested selects. But since it could be called as an edit function within an entry, I could extend my report setup window to incorporate EasyWriter.

OI's Report Builder is more problematic. Here the report design is supposed to be encapsulated in the Repository. To design your own report structure, you must abandon the Report Builder tool. Some of my customers will dislike this aspect of conversion from AREV to OI, as the reporting capabilities in OI are clearly less functional than AREV's from the user's standpoint.

However, in AREV I had little windows for "Enter Date" or "Enter Date Range" as you describe, and many reports required multiple execution steps. In OI, I redesigned my report execution to require none, one, or possibly two steps in execution. This includes the selection of view, printer, capture, email or FTP transmission; in-line selection command replacement including query table recall; and user input through parameter replacement.

Maybe I'm just a better programmer now (unlikely), but I think this just couldn't be accomplished with AREV. For ideas, you can see this report definer in the ATLAS Development Framework on the WORKS disk. Also, Kudos to Roger at SRP who helped with this specific project.

We also developed a "shell" around rlist statements (actually this was orinally developed in AREV and converted to OI). It allows for programmer/user defined selection criteria. If you pass in a list statement with Date=?"Enter Date"? it will prompt for a date on the fly. I agree it would be nice if this could be supported directly in Rlist but we knew that going in.

Also, to the best of my knowledge OI does support nested selects however it is very picky about the syntax. You have to have your () parens with spaces. I think you will find that this example will work:

SELECT ORDERS ( WITH DATE_CREATED=5/4/06" OR WITH DATE_CREATED=5/3/06" ) AND ( WITH STATUS=OPEN" )

hth,

John

Maybe I can make this clearer. In the report definition part of my reporting shell, I can define tokens such as $M and specify the user input prompt and validation for that token, say "Enter Module name." Then the report execution shell prompts for the user input, as opposed to RList doing the prompting. In the RList sentence, I have "AND WITH MODULE '$M]'" instead of the "?text?" syntax.

By removing the in-line prompting feature from RList, OI has forced me to be more innovative in designing a proper user interface for reporting. Looking back, I have to say that removing this feature from RList represents an opportunity, not a problem.

Agreed… Its just another one of those things to consider when converting from AREV to OI.

John

You could do it in arev, just as in OI, with a multitude of little windows or with a 'smart' window that changed controls before loading. Or, take the easier way and use a few steps - one for output, then a second to select (which could be a query window, one or more collectors or cheat and use ?? in the command - something some users liked to do, also). The same in OI – you can do it any of these ways, but by adding OIPI info/buttons to selection windows, you cut the entry for a report, but at the same time add many more windows (and maintenance). All is a matter of style and preference, however, not really anything about functionality.

Since all of our reports to the OIPI viewer except 4 that cannot be made to fit (they prompt for filenames to save them, for use in excel - again, once a year reports to do with W2's), most of what you are probably displaying in your windows isn't necessary for ours - only select criteria is displayed and the report shell builds a select. Which works for most of the well over 100 reports there.

None of which address the () problem. It turns out that sometimes the () will work - if you add lots of spaces and if it the first thing after the filename (which should be irrelevant). The annoying case sensitivity of run_report is another PITA (if it really cares, just do a quick UpCase on the command that isn't inside quotes, otherwise, do so before checking for the dict name of fields in the select phrase).

I may add something similar (but not quite the same), as the only select style my shell doesn't have quite yet is "ask the user for unvalidated input"). Easy enough to add and will solve this tiny problem.

Of course, I ran into another run_report issue. Using MV fields, sorting on and break-on with 'V' or 'BP' results in incorrect values displayed (with 'V', the last value doesn't appear, with the second to last one repeated, while with 'BP', only the last value is used in headers). I've already added it to the bug report list.

View this thread on the Works forum...