Many years ago there was discussion in these newsgroups about whether
the keystroke macros would continue to be supported by future versions
of Qpro. This apparently is the case because when we recently tried to
run a complex one of 50,000 odd keystrokes on Qpro 11 (XP) and Qpro 7
(98SE) it failed, although it runs flawlessly on DOS, Win3.1, and Win98.

We have tried using the debugger, and saving it in different formats and
rerunning, all to no avail. It appears that some commands and/or formats
have been modified, replaced or dropped, and that there may be conflicts
with shortcut keys. Were guidelines ever released to assist users in
converting those macros?

Thanks...

RAB

R.:
> whether
> the keystroke macros would continue to be supported by future versions
> of Qpro.

Please define: "keystroke macros"


> This apparently is the case

I assume that a "not" is missing there.


> It appears that some commands and/or formats
> have been modified, replaced or dropped . .

Yes.

> . . and that there may be conflicts
> with shortcut keys.

Possibly. I know no details.

> Were guidelines ever released to assist users in
> converting those macros?

Not that I know of. Specific queries here may elucidate useful replies.


I do not know whether this affects your project:

Tools|Settings|Macro|[ ]Slash Key compatibility
--
Good wishes!
Roy Lewis
C_Tech volunteer
(UK)

Thank you...

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.

"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. Regardless, we decided that it would be prudent to program
our apps from scratch as standalones and compile them for whatever
platform was required.

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.

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

Thanks again...

RAB

lemoto wrote:
>
> R.:
> > whether
> > the keystroke macros would continue to be supported by future versions
> > of Qpro.
>
> Please define: "keystroke macros"
>
> > This apparently is the case
>
> I assume that a "not" is missing there.
>
> > It appears that some commands and/or formats
> > have been modified, replaced or dropped . .
>
> Yes.
>
> > . . and that there may be conflicts
> > with shortcut keys.
>
> Possibly. I know no details.
>
> > Were guidelines ever released to assist users in
> > converting those macros?
>
> Not that I know of. Specific queries here may elucidate useful replies.
>
> I do not know whether this affects your project:
>
> Tools|Settings|Macro|[ ]Slash Key compatibility
> --
> Good wishes!
> Roy Lewis
> C_Tech volunteer
> (UK)

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

Hi Roy....

Thanks for your suggestions.

The Tools|Settings|Macro|[ ]Slash Key compatibility check off
eliminates some problems but, unfortunately, not all of them. It's not
feasible to try to sort the remaining conflicts for a single app. As I
noted to Uli, one option would be to buy a used 98 and load an old Qpro
or 123. We have several "orphan" programs whose computers have long
since been scrapped. As luck would have it, we just scrapped a suitable
computer in June.

Thanks again...

Bob Becker



lemoto wrote:
>
> R.:
> > whether
> > the keystroke macros would continue to be supported by future versions
> > of Qpro.
>
> Please define: "keystroke macros"
>
> > This apparently is the case
>
> I assume that a "not" is missing there.
>
> > It appears that some commands and/or formats
> > have been modified, replaced or dropped . .
>
> Yes.
>
> > . . and that there may be conflicts
> > with shortcut keys.
>
> Possibly. I know no details.
>
> > Were guidelines ever released to assist users in
> > converting those macros?
>
> Not that I know of. Specific queries here may elucidate useful replies.
>
> I do not know whether this affects your project:
>
> Tools|Settings|Macro|[ ]Slash Key compatibility
> --
> Good wishes!
> Roy Lewis
> C_Tech volunteer
> (UK)

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

R. A. Becker wrote:
> 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.

Okeydoke.

> 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.

I understand you better here, too (I think).

> I think the problems started with the two versions of Qpro7.

I think that's correct. As best I can recall, with QP7 I ended up converting
most of my old macros to the new standard because of problems encountered. I
left only one or two files with slash command syntax, which surprisingly still
ran even under QP8, but I finally thought it unwise to keep pushing my luck.

> The one that runs on 98 is different than the one that runs on 98SE.

I'm not aware of different versions. My QP7's system requirement was Win95, but
I ran it under Win98SE.

> 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 suppose even if "everything's done right," sometimes you might still be
overcome by developments that trump all prior measures taken.

> 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.

I think what you're dealing with here is different default handling in different
QP versions for data types within macro commands. Not sure what the syntax and
defaults where in prior versions, but in QP8 {LET} includes a parameter option
to FORCE data type when there's ambiguity. In QP8

{let ga48,CX18..EB54}

enters the value residing in CX18 into GA48 (just like QP11 does), whereas

{let ga48,CX18..EB54,s}

enters the string "CX18..EB54", as the original macro apparently intended. QP
Help for {LET} makes clear that in case of ambiguity, it will treat any entry as
a value (if possible), and only if unsuccessful as a string. It seems that
prior versions had a different approach.

BTW, the ~ following your {let} command is superfluous; it neither accomplishes
nor hurts anything.

> 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.

Don't know if it would work, but you might try running an older QP version in
compatibility mode.

Cheers,
Uli

Hi Roy...

Just a follow-up.

When we developed the macro we also set it up on a 123 spreadsheet.
After spending a week trying to sort the Qpro version, I tried the 123
spreadsheet on an old 123W version running on both a 98SE and a XP but
it failed. I just realized that failure was the result of the same
string problem I had discussed with Uli. With the string problem
corrected, both the setup and data processing aspects of the macro run
flawlessly. Problem solved. I don't anticipate any future requirements.
It's health care related and its standalone siblings are preferable.

Thanks again...

Bob Becker

Hi Uli...


> I understand you better here, too (I think).

I'm an engineer/entrepreneur (semi retired) who's been involved with
computer apps in factories, offices, and health care since '59. Learned
to program early on to avoid being bamboozled by the techies.

> I'm not aware of different versions. My QP7's system requirement was Win95, but I ran it under Win98SE.

Checked our files. The WP Suite7s that we have had 2 CDs, Wps7_cd1 and
Wp_16bit, they have different components. We have the former in a 98SE
and the latter in a 98. The latter has something called a 1-2-3 Macro
Translation Assistant (123toqpw.wb2) but I don't know how or if it
works.

> {let ga48,CX18..EB54}

In retrospect the {let ga48,CX18..EB54} type lines were slip ups. All
other strings were enclosed in quotation marks as, in my opinion, they
should have been.

When we developed the macro we also set it up on a 123 spreadsheet. When
the Qpro version had problems I tried the 123 spreadsheet on an old 123W
version running on both a 98SE and a XP but it failed. I just realized
that failure was the result of the same string problem as above. With
the quotation marks added, both the setup and data processing aspects
run flawlessly. Problem solved. I don't anticipate any future
requirements. It's health care related and its standalone siblings are
preferable.

Thanks again...

Bob Becker