I have a PROC I'm trying to do a SORT .... HEADING
command in, but the input string is provided earlier in the
proc, by an old screen-builder application, and I'm not
allowed to fix the behavior of including single quote marks
around it. As a kludge I use this tainted string by doing
a @`echo stuff` on the stuff in that input string, {am
on d3/linux, but on d3/nt I guess a basic program
ECHOGUY could tclread and crt his command line args
minus the quote marks} but this seems needlessly hard.

Is there a simpler way to do some conversion on a
provided command buffer?
I looked through all the D3 HELP docs that show user
exits, but nothing appealed.

001 PQ we_say_so
002 S3
003 IH'2 bobs desk (32 bobguy bobacct , prntq 42)'
004 C ---end of driver-supplied proc lines---
005 Hsortc fish heading "AQ007 FISH
REPORT 'T' PAGE 'PL'
006 H Prepared for :
007 H@`!echo
008 A3
009 H`
010 H 'LL'" ID-SUPP
011 P

On 2011-04-22 17:28:52 -0400, "Frank Winans" <fwinans (AT) sbcglobal (DOT) net> said:


PROC Should have died a long time ago, so I would likely rewrite it in
BASIC, but if you must keep your PROC in tact, that is easy enough as
well.

Create a BASIC program using PROCREAD AND PROCWRITE statements to pick
up the original buffer, strip the quotes, then write it out again.
It's also nice that this approach can be used on all platforms.

STRIP.QUOTES.PGM
001 PROCREAD BUFFER THEN
002 CONVERT "'" TO "" IN BUFFER
003 END ELSE
004 BUFFER = 'ERROR'
005 END
006 PROCWRITE BUFFER

001 PQ we_say_so
002 S3
003 IH'2 bobs desk (32 bobguy bobacct , prntq 42)'
004 C ---end of driver-supplied proc lines---
005 HSTRIP.QUOTES.PGM
006 P
007 IF A1 = ERROR X-COULD NOT READ BUFFER!
008 Hsortc fish heading "AQ007 FISH REPORT 'T' PAGE 'PL'
009 H Prepared for :
010 A3
011 H 'LL'" ID-SUPP
012 P

--
Kevin Powick

"Kevin Powick" wrote

Ah, but procread/procwrite is a blunt tool -- it reads/writes ALL the
buffers,
and though my example only mentioned S3 / IH, this app. provides like
4 or 5 buffers of std info about the program run. Reminds me of named
common.
The D3 help docs seem to indicate that procwrite puts each word in a
different
buffer. So your prog would work nicely aside from nuking my other buffers.

But I still could use in on d3/nt since windows doesn't strip quotes when
you
try to @`!echo 'quoted text` -- or, like I said, use tclread of
cmdline args.

I was afraid there was no easy way to doctor just one buffer, but just had
to ask.

I haven't really wanted to use Proc much, since macros are way easier to
read, but I hate Proc less when I have to stop and write a basic program to
recreate some minor feature of Proc, like remarks lines that don't trash
your
active select list the way REM does in Proc, or aborting program launch if a
select list is unexpectedly absent or user has typed in an invalid keyword
for this
massive report. Also, I prefer collecting that sort of program setup
details in a
Proc instead of buried down in the Basic program itself, esp. since it may
need
adjusting from year to year or from account to account. Some of our basic
progs
are admittedly bigger than good practice dictates, so it is a treat to avoid
tweaking
them just for transient department manager's whims.

On 2011-04-25 03:52:18 -0400, "Frank Winans" <fwinans (AT) sbcglobal (DOT) net> said:

It is easy enough within BASIC to manipulate the buffer that you wish
as it is just a delimited string.

It wouldn't nuke anything. You can parse and rebuild the output buffer
any way that you wish. The real problem that you are going to have is
that, without any quotes, PROC will look at buffers as being delimited
by spaces. So, while 'HELLO THERE' fits into a single buffer, HELLO
THERE without quotes requires two buffers. Perhaps that's what you
meant about my original program nuking buffers when it stripped the
quotes?

The point of my post wasn't to deliver a fully working solution, but to
mention the PROC READ/WRITE statements, as your original post seemed to
indicate that you were unaware of them. I.e. using TCLREAD

I was unaware of this REM problem. I've always used "C" for comment
lines in Proc. No select list problems. I.e.

001 C ** This is my comment - Asterisks not required
002 C This is another comment

Checking error "E" codes can avoid this problem.

--
Kevin Powick

"Kevin Powick" wrote
Sorry, I meant to write "the way REM does in Macro",
not "... does in Proc."

I too use C in Proc, works fine there. As I
recently posted, I wrote an empty proc REMM with just
PQ on the sole line, that works fine if I use it instead of REM
in Macros. My active select lists are safe, at last... REMM
Doesn't add to the cluttered state of my custom basic file,
and is easy to remember when I service a new client.

On Apr 25, 6:40*am, Kevin Powick <nos... (AT) spamless (DOT) com> wrote:
As Kevin points out, the problem is that proc delimits its buffers
with spaces. So if you want spaces in a particular proc buffer you
need to surround the string with quotes, which works fine until you
need to use the quoted string in access. My fix is like Kevin's basic
example: remove the quotes but also convert the spaces to underscores
before procwriting the proc buffer.

/Scott Ballinger
Pareto Corporation
Edmonds WA USa
206 713 6006

"Kevin Powick" wrote
I dislike deferring data checking to the basic program run though;
by then you've probably cleared the previous menu and maybe
proudly announced "Program MegaWhopper active: please wait" or whatever.

Better to tweak a menu system proc to detect the problem, gripe at the
bottom
line, and make them fix whichever data entry slot they've goofed up.
Macros are easier to read than procs, and I love them for that, but in turn
procs are easier to read than programs, so ditto.