One of the things I miss when I write macros instead of procs is
detecting when a Select command fails, and bombing out of the macro.

So where I could just put a line in PROC that says IF #S X
I need to write a program that does that for use in macros. Here it is.
Written for D3 ; sorry, I don't get to play with the other flavors, really.

Program ABORT#S()
* example: n
* select md 'off'
* abort#s
* list only md
*
Myname = system(45) ;* "abort#s"
* Make a select list name like "foo30.0" for pick port 30, no pushes
* we cannot delete this list ourself. get-list oughta have a (D option
Mylistname = 'foo':@PIB: '.' :SYSTEM(16)

If system(11) else
crt 'Oops, no active select list -- doing an ABORT now via ':Myname
ABORT
end

* Preserve the active select list so next line of the macro sees it too
execute 'save-list ' : Mylistname capturing bucket
chain 'get-list ' : Mylistname

On 2011-06-28 22:37:31 -0400, "Frank Winans" <fwinans (AT) sbcglobal (DOT) net> said:

Except for legacy support, why is anyone still using Procs and Macros
over BASIC?

--
Kevin Powick

"Kevin Powick" wrote

If several variations of a certain report get used enough,
we commit them to a macro to save typing, since sometimes
several staff are logged into the same utility 'userid' and may have
the command stack locked briefly. We try to name these related
macros but with minor variations for screen width, etc with similar
enough names to sortc the md for them later on for housekeeping.

Unless that report is just overwhelmingly frequently run, it doesn't pay
to clutter up a program file with a basic screen to prompt for parameters
and do an Execute. Some of our staff are comfortable with tracking
down macro shortcomings on their own, but if presented with a program
driven report giving odd results they will instantly hand it off to an
engineer.

We've earned these perhaps quirky habits from long experience in
linux/unix/aix, where you tend to use a string of small stock text-handling
programs {'filters'} run sequentially on the base report information to
make a sort-of-what-you-wanted printout with very minimal effort.

If we instead preferred programs we'd probably want to whip up something
like the HELP command to document all the various ones with various
keywords, references to other programs and files and projects,
'destroy-after'
date, etc. It just doesn't pay to rely on some guru senior staff to have
all that
stuff memorized; next thing you know they have a heart attack or something.

Frank
Frank

I use macros for some of the reasons Frank cited. Sure, they're very
limited, and I move to BASIC as soon as something is needed beyond its
limitations. When confronted with an inability to chain or invoke an
external macro in another file like Proc [sub] and (chain), I wrote
the functionality, but I wouldn't go much further.

Side-tracking a bit: I use D3 menus too, never use D3 Screen
functionality, and want to get a better handle on Paragraphs, which
are quite useful and also cross-platform for the most part.

T