DAVE POCIU - THANKS (OpenInsight Specific)
At 27 MAR 1998 12:01:52PM glenn bryant wrote:
Dave, this morning I found your original submission for the program to print programs in a useable fashion. It's hard for me to believe that such a feature has to be added to OI from the outside, but there it is. I've been bugging support for a year to find out how to do this, and kept being told it couldn't happen. Thanks again. Many beers have been logged to your credit in my accounts.
For the benefit of anyone else who hasn't figured this out yet, I'm posting below my version of your program, which prints in portrait mode condensed on virtually any dot matrix printer.
glenn bryant
bitmarine@aol.com
FUNCTION PLIST(PROGRAM_NAME)
* WRITTEN BY DAVE POCIU 07JUL1997 - modified by GLENN BRYANT 03MAR1998
* At the EXEC line in System Editor type RUN PLIST "xxxxx"
* where xxxxx is the name of the stored procedure you wish to printCONVERT @LOWER_CASE TO @UPPER_CASE IN PROGRAM_NAME
EQU NEWPAGE$ TO CHAR(12)
EQU CONDENSED$ TO CHAR(27):CHAR(15)
EQU RESET$ TO CHAR(18)
APPLICATION=@APPID
ROW_ID=PROGRAM_NAME:"*":APPLICATION
PROGRAM=XLATE("SYSPROCS",ROW_ID,"","X")
IF PROGRAM=" THEN RETURN "* Program ":PROGRAM_NAME:" not found" SWAP @FM WITH \0D0A\ IN PROGRAM; * CRLF REPLACING @FM SWAP \09\ WITH " " IN PROGRAM; * REPLACE TAB CHARACTERS WITH 3 SPACES OSWRITE CONDENSED$:PROGRAM:NEWPAGE$:RESET$ ON "PRN" RETURN "OK ":PROGRAM_NAME:" printed" </QUOTE> —- === At 27 MAR 1998 01:15PM Dave Pociu wrote: === <QUOTE>Glenn, I'm glad I could help (I might take you up on the beer offer ;) ). Actually, I further refined that program since, but it's using OIPI. It can now be called without a program name attached, in which case it opens a form that allows the developer to choose the procedure from a list. Also, I am talking with RevSoft about the possibility of including the following 3rd party tools in one of the next Works CDs in order to help people in migrating from AREV to OI and also for easier window data control in OI: Problem: In Arev, in order to modify a screen control or perform a calculation programatically, we used to change @record, and then "post" the contents of that variable on to the corresponding screen controls In OI, we can use the RECORD property, but there's no way to "post" it's contents automatically back to the screen controls. This has to be done manually, control by control. This means that a lot of the AREV programs that deal with screen control need SUBSTANTIAL changes to them. Solution: In the past year and a half I developed 2 utility procedures that allow the developer at design time to specify which controls should have their data collected in what field in a variable (Gather function). I also have the reverse function (Show function) , that takes the variable, and based on the design-time specifications, fills the screen controls automatically with the data from the variable. So at this point, any AREV program that dependeds on modifying @record and then having those changes posted to the screen automatically can do the following: Gather (…) ;* specify in which variable to gather and based on which specification (you can have different multiple specs) Your ORIGINAL AREV code that deals with @record/@pseudo/whatever here
Show(…) ;** post the changes made back to the screen controls
I also use this intensively to collect data in order to pass it to a detail (child) window and return the information in one variable that allows me to keep everything syncronized. Thats because I can just update one variable that has all/some of the screen info instead of control by control.
I am curious as to the level of interest for this. I plan on having my laptop with an application of this technique at the Boston conference. If anyone is interested in more details, please e-mail me at d.pociu@snet.net
Thanks