R. A. Becker wrote:
> My definition of a "keystroke macro" is one written by manually keying
> in each element, including menu commands (/), much as one would write
> computer source code. It's been 20 years or more but I recall that was
> the only way macros could be written when 123 and Qpro were first
> released.

The prevalence of slash commands in macro code back then is certainly true ...
although I absolutely don't get your comparison of keying in slash commands to
how "one would write computer source code" (?!?) ... but that's beside the
point. Nevertheless, even in those early years, spreadsheet macro language
included conditional and looping capabilities (IF, FOR, etc.) you couldn't
invoke "via the menu". Indeed, I built custom menus in 123 "more than 20 years
ago", and you surely couldn't do that using slash commands.

> "not" supported is correct. Since the issue was of serious concern to
> many users, I assumed at the time that Corel would release some
> guidelines.

As best I recall, the warning was issued as part of the QP5 release -- and what
to this day is probably the best (and last) QP manual, the QP5 manual contained
a lengthy list of slash commands and their corresponding bracketed commands. At
the time they warned that some slash commands would continue to work for several
more versions, but that eventually most slash commands would cease to function
because they did not plan to support them indefinitely. For that reason they
recommended that users gradually convert all their macros to the newer standard.
(Although I quickly began to use the newer commands in new spreadsheets, some
of my older spreadsheets didn't get converted until QP8 (!), and even then much
of my slash command code still worked, but that was probably just luck.)

The main problem with slash commands is that even during the heydays of slash
command syntax, QP (as well as 123) occasionally changed the menu structure,
thereby rendering any fixed slash command sequence potentially nonsensical. In
essence, that's the problem with slash commands: unless you know exactly where
any given slash command sequence takes you within the menu structure, you're
blind trying to follow the logic of your code. In short, to understand your
legacy macro code, you actually need the prior version to see the logic. That's
the risk in attempting to port old code to a newer version ... you're jumping
out of the plane hoping there's a parachute strapped to your back (without
checking first it's really there).

Thus, bracketed macro code is independent of the menu structure of any
particular version, and thus more portable.

> We can't pinpoint where the problems are, so can't be specific. In
> general, several functions seem to be confusing cell addresses and cell
> content, but we can't identify where.

Back then, as now, functions can be part of macro code, but the flawed return
value of a function has nothing to do with the functionality of slash commands
(but feel free to refresh my memory). These are separate issues.

> We'll try Tools|Settings|Macro|[ ]Slash Key compatibility and let you
> know.

I think Roy's on to something here, in principle. It has the potential to solve
some of your dilemma, at least somewhat -- but 50,000 keystrokes of code ...
hold on to the railing!

Your scenario is a textbook example of how important (macro) documentation is.
The more you rely on legacy, the more you rely on the coder having done what is
oh so easy to neglect -- document the algorithm. That's why some of the highest
paid programmers today supposedly are COBOL (!!) programmers -- an
ever-shrinking club of repairmen of yesterday's technology. Ironic, isn't it?

Cheers,
Uli