How to handle IO Redirection in low level windows
Hi - I am working on a project for a company that used to use ACCEPT and DISPLAY statements. We have implemented a UI Class that performs "accept" statements by using w_disp(MainWindow, WD_ACCEPT, charnum)
This is done in a loop to try to reduce as much code change as possible. So, if previously, they had a loop that did this:
var = ""
looper = 0
accept(...)
incr looper
var(looper:1) = accept_char
Now, we basically have:
var = ""
looper = 0
newchar = ui.acceptcharacter()
incr looper
var(looper:1) = newchar
There's obviously more to it than that, but this is more-or-less what was changed.
The problem we are having is using IO redirection. For example, if you have a command line such as
dbr prog < input.txt
w_disp with WD_ACCEPT does not use stdin, so therefore the values in input.txt are not making it into the program.
Does anyone have any idea on how to make this work?
Some of the ideas we have toyed with:
- Change WD_ACCEPT to WD_READS which does seem to use stdin. This would require going back to every program and changing the input loops, so this is a bit low on the possibility list.
- Change the program to look for an input file as a command line parameter and if passed, return the next character from this file rather than from the keyboard - this has some promise as it would be implemented in a single place
- Change the program to look for an environment variable and if it is set, use ACCEPT rather than W_disp - this may have some promise as again, the effect would be to a single routine, but we don't know what impact this would have on the entire system, so we are a bit concerned about using this.
Any other thoughts?
Thanks in advance.
Gary.
Do they have this loop for every field entered on screen, or is this an application with only a few entry fields ?
Have you any way of knowing when you are accepting the field character in a field ? If so you could do a READS and store in a property and then every subsequent "ACCEPT" would pick off the next character form the string held as a property
Usually ACCEPTS are used so the applciation can handle delete keys, arrow keys and function keys. Can a READS (or the low level windows equivalent) only detect CR/LF as a delimiter, or can you set it to trap other keys as field delimiters?
On a separate note, are tehy doing this redierct for testing purposes, or does their application actually run that way ?
If its for testing, then I suspect they would need it in every program, but if its only a few progarms maybe those ones could be handled differently , and without having to change the coding for every field in every program.
I thought everyone wrapped ACCEPT loops in an "XCALL INPUT" subroutine.
Thankfully, in this case, there is are input routines, so only about 5 or 6 out of many hundreds of programs actually changed to implement the UI class for input - many hundreds of programs changed for screen output as these were all changed from DISPLAY statements to calls in the UI Class.
We have decided to go with my original thought #3 - change the UI Class to look for an environment variable and if set, open the TT: on a channel and do ACCEPT and WRITES rather than w_disp(...,WD_ACCEPT...) and w_disp for display. This is testing out well at this point.
The main application will not use this when being used interactively, but they run a number of automated programs at day end, month end, year end and in those cases, we want to be able to run using IO Redirection.
The benefit of the change we put in is that it is completely isolated to a single class - the UI Class. No application changes were needed to implement it. The only caveat is that they need to set an EV before executing if they want to use IO Redirection. That's pretty minor since it is wrapped in the automated routines anyway.
So, thanks for the input - hopefully we have a solution that will prove to go well.