Hi Uli...

I didn't mean to imply that the menu commands were the sole components
of macros. They do, however, seem to be a major part of my problem
(perhaps THE problem) because they don't execute correctly.

When writing source code (but not the OS compatibility and graphics
stuff) I input every character of every line of functional code
manually. That way when it fails to compile I can usually spot the error
quickly. We primarily work with console apps for broadest applicability.
My focus is on conceptual viability, not productivity.

Your comments about the evolution of the menu commands make good sense.
I don't have the ver5 manuals but do have Borland's ver4. They're also
excellent. I think the problems started with the two versions of Qpro7.
The one that runs on 98 is different than the one that runs on 98SE. I
haven't followed the issue since the early '90s. When it first came up I
decided we should program critical stuff from scratch rather than get
caught on the upgrade treadmill. We still use Qpro but no complex
macros.

I agree that documentation is critical for both macros and source code.
This macro was thoroughly documented at the time but hadn't been used
for 15 years. I can still "read" it though. We had it on disks along
with printed operating booklets but the boxes of development stuff,
documentation, and old spreadsheet manuals were archived and difficult
to dig out. Hence, my query.

I ran the macro on different platforms side by side and discovered
things like, while {let ga48,CX18..EB54}~ worked on early versions,
later versions required {let ga48,"CX18..EB54"}~. On Qpo 11, the former
placed the contents of CX18 in ga48 so {put @cell("contents",!ga48)...}
would return an error. Some fun.

Roy does have part of the answer. The macro has two phases, setup and
data processing. The data processing phase, which has relatively few
menu commands, ran with some minor problems on Qpro 11 (XP) after
checking the slash key compatibility box. However, the setup phase with
literally hundreds of menu commands crashed. If I can sort the data
processing problems, I'll try to set up the spreadsheet manually. We'll
see. I'll also check craigslist locally for a used 98. Ironically, we
just scrapped one in June.

Sorry about any misunderstandings.

Thanks...

Bob Becker


Uli wrote:
>
> 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