PainShop Pro Scripting - The UNDO twilight zone

Author

The UNDO twilight zone

Fabrice Roux

2006-06-03, 7:29 pm

In article <447EF71B.B949E551@agabatur.xednaps>, SpRu@agabatur.xednaps
says...
> SuzShook wrote:
>
>
> Might be related to undo optimization.

Let me jump in... Does anyone understands how the optimization works? For
what I understood a long while ago it is supposed to disable the UNDO for
each step run during a script. So only one version of the image was
backuped before the script.

In fact when you run a long script you notice that at each step an undo is
created. Therefore saturating the ressources of the computer. (CPU, RAM and
HDD)

So I'm looking for some inputs now... how does the PSP undo system works?

ps: I can't seem to get my hands on Paint Shop Pro Undo for dummies.

--
Fabrice Roux aka [RS]Faramir_agst
PaintShop Pro and Tribes scripts
http://www.fabriceroux.com

Spandex Rutabaga

2006-06-03, 7:29 pm

Fabrice Roux wrote:

> how does the PSP undo system works?

Mysteriously.

> ps: I can't seem to get my hands on Paint Shop Pro Undo for dummies.

It must be described in the revolutionary learning center. That's
the part for dummies.

I am afraid I have no idea what happens in the PSP undo system.

SuzShook

2006-06-03, 7:29 pm

Fabrice Roux wrote:
> In article <447EF71B.B949E551@agabatur.xednaps>, SpRu@agabatur.xednaps
> says...
>
> Let me jump in... Does anyone understands how the optimization works?
> For what I understood a long while ago it is supposed to disable the
> UNDO for each step run during a script. So only one version of the
> image was backuped before the script.
>
> In fact when you run a long script you notice that at each step an
> undo is created. Therefore saturating the ressources of the computer.
> (CPU, RAM and HDD)
>
> So I'm looking for some inputs now... how does the PSP undo system
> works?
>
> ps: I can't seem to get my hands on Paint Shop Pro Undo for dummies.

It's SUPPOSED to work as you describe, Fabrice - a single copy of the image
at the beginning of the script, and no further copies made. It appears as
if perhaps the step UNDO data is still created by the individual steps, but
then discarded at the end of the step rather than being kept when the
EnableOptimizedScriptUndo step is included in the script. That's a memory
savings in the long run, but costly for each step, if the data is being
saved, especially for large images. Only Corel can tell us for sure, and
they don't frequent these NGs. Suz

Joske

2006-06-03, 7:29 pm

SuzShook wrote:
> Fabrice Roux wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> It's SUPPOSED to work as you describe, Fabrice - a single copy of
> the image at the beginning of the script, and no further copies
> made. It appears as if perhaps the step UNDO data is still
> created by the individual steps, but then discarded at the end of
> the step rather than being kept when the
> EnableOptimizedScriptUndo step is included in the script.

I had to break my head over this a while back too. It's just one of
many mysterious actions behind the scripting... no insight into it
for us users at all. I think I concluded that the
EnableOptimizedScriptUndo is somehow related to, or based on, the
Apply process.

In order to be able to Undo the script as a whole, the individual
Undo options that we have when normally working in PSP have to be
disabled. But those options of undoing the individual steps
apparently couldn't be taken out of the scripting process
completely, which is why there is evidence of them.

When for instance working with the Warp Tool, you can Undo each move
individually and continue making more - until you hit Apply. Apply
seems to wrap up all the moves into one, yet... there is no UnApply.
It is not a single action that can be undone: you will have to Undo
all the steps it contains. I think the programmers somehow managed
to UnApply a script, but not to skip that individual Undo process
completely.

Equally, if my hunch from back then is on the right track at all,
this could explain why the number of Undo's set in Preferences is
not respected. I think there have to be Undo's even if someone has
the undo system disabled. They have to, because they are needed for
all the tools that use Apply. They would in fact be different Undo's
than the regular ones (like the single action of applying a Drop
Shadow).

Anyone, do tell me if this makes sense. It's been a while I tried to
figure this out.

Joske
--
http://members.home.nl/j.a.c.backer/

SuzShook

2006-06-03, 7:29 pm

Joske wrote:
> SuzShook wrote:
>
>
>
>
>
>
>
> I had to break my head over this a while back too. It's just one of
> many mysterious actions behind the scripting... no insight into it
> for us users at all. I think I concluded that the
> EnableOptimizedScriptUndo is somehow related to, or based on, the
> Apply process.
>
> In order to be able to Undo the script as a whole, the individual
> Undo options that we have when normally working in PSP have to be
> disabled. But those options of undoing the individual steps
> apparently couldn't be taken out of the scripting process
> completely, which is why there is evidence of them.
>
> When for instance working with the Warp Tool, you can Undo each move
> individually and continue making more - until you hit Apply. Apply
> seems to wrap up all the moves into one, yet... there is no UnApply.
> It is not a single action that can be undone: you will have to Undo
> all the steps it contains. I think the programmers somehow managed
> to UnApply a script, but not to skip that individual Undo process
> completely.
>
> Equally, if my hunch from back then is on the right track at all,
> this could explain why the number of Undo's set in Preferences is
> not respected. I think there have to be Undo's even if someone has
> the undo system disabled. They have to, because they are needed for
> all the tools that use Apply. They would in fact be different Undo's
> than the regular ones (like the single action of applying a Drop
> Shadow).
>
> Anyone, do tell me if this makes sense. It's been a while I tried to
> figure this out.
>
> Joske

Well, for what it's worth, here's what I think happens:

1. If you have the Undo system disabled in PSP, it has no effect on a
script, except to disallow any Undo steps - those will cause the script to
fail. Setting a limit on the number of Undo's allowed works within PSP, but
is ignored by scripts.

2. The EnableOptimizedScriptUndo (EOSU) command is available merely to
reduce the amount of information a script retains. I believe the save
information is still generated by every step, but is then discarded when the
step terminates if EOSU is present. I think it's a memory-saving thing -
since the script can only be "undone" as a whole, it's pointless to retain
all that intermediate "undo" information, so it's discarded.

3. If steps are to be "undone" as part of the script, the EOSU command
is disallowed, and the step "undo" information is retained for the life of
the script, thus allowing those "undos". For a long and complex script,
this can add considerably to the memory required to run the script.

4. And here's the anomaly - using the EOSU command should make
"undoing" a script very easy, and one would think it should be rather
instantaneous - replace the script-altered image with the original image
saved at the outset of the script. However, if you've ever "undone" a long
and complex script, it's not that simple - the system churns and churns and
churns - almost, it seems, undoing all the steps individually! That's not
what's supposed to be happening at all - but one wonders!

Suz

Spandex Rutabaga

2006-06-03, 7:29 pm

SuzShook wrote:
>
> Joske wrote:

Some tools like Crop, Background Eraser, Warp, Perspective Correction,
Straighten, Deform etc. seem to have a special state during the life
of the tool. It is possible to undo Straighten but retain the angle
of the annotation while you are in the Straighten tool. However, if
you switch to another tool and come back to Straighten that angle is
lost. Ditto of the Crop annotation and so on. However, it's hard to
see how this would be relevant to a script that resizes and sharpens
an image.
[color=darkred]
>
> Well, for what it's worth, here's what I think happens:
>
> 1. If you have the Undo system disabled in PSP, it has no effect on a
> script, except to disallow any Undo steps - those will cause the script to
> fail. Setting a limit on the number of Undo's allowed works within PSP, but
> is ignored by scripts.
>
> 2. The EnableOptimizedScriptUndo (EOSU) command is available merely to
> reduce the amount of information a script retains. I believe the save
> information is still generated by every step, but is then discarded when the
> step terminates if EOSU is present. I think it's a memory-saving thing -
> since the script can only be "undone" as a whole, it's pointless to retain
> all that intermediate "undo" information, so it's discarded.

I think undo information has to be saved for each command in the
script until the script completes because individual commands could
be run in interactive mode and, for instance, canceled to abort a
script part way through.

> 3. If steps are to be "undone" as part of the script, the EOSU command
> is disallowed, and the step "undo" information is retained for the life of
> the script, thus allowing those "undos". For a long and complex script,
> this can add considerably to the memory required to run the script.
>
> 4. And here's the anomaly - using the EOSU command should make
> "undoing" a script very easy, and one would think it should be rather
> instantaneous - replace the script-altered image with the original image
> saved at the outset of the script. However, if you've ever "undone" a long
> and complex script, it's not that simple - the system churns and churns and
> churns - almost, it seems, undoing all the steps individually! That's not
> what's supposed to be happening at all - but one wonders!

Pure guesswork, but this might be some complexity relating to selective
undo.

Joske

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
> SuzShook wrote:
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> Some tools like Crop, Background Eraser, Warp, Perspective
> Correction, Straighten, Deform etc. seem to have a special state
> during the life of the tool. It is possible to undo Straighten
> but retain the angle
> of the annotation while you are in the Straighten tool. However,
> if you switch to another tool and come back to Straighten that
> angle is lost. Ditto of the Crop annotation and so on. However,
> it's hard to see how this would be relevant to a script that
> resizes and sharpens an image.

Script code will include all the actions except undo and unless you
cancel during some of what you call those special states (for
instance not Crop, but definitely Warp). But that wasn't what my
hunch is about.

I'll again compare to the Apply these tools need, after what you
call their life.

What I'm suggesting (guessing) is that EnableOptimizeUndo works
similar to the contrary option of Apply: the Cancel. You can cancel
all individual actions (say strokes) you took with such a tool in
one go. Similarly, you can undo a script in one go (it will do the
work for you, irrelevant whether it takes a short or long time). You
don't have to manually undo all the steps from a script.

However, once you have hit Apply for such a tool, you will have to
manually undo one by one all the actions you took before. The
command Apply itself cannot be undone. My hunch is that there is a
connection to what EnableOptimizeUndo does.

In PSP 8 you could see the undo's of regular tools like the Paint
Brush in recorded script code. With EnableOptimizeUndo you won't
find them in scripts. But even in PSP 8 you will not find the undo's
made during Warp once Apply has been hit. And in neither version
will you find anything about Warp when you hit Cancel instead of
Apply.

That latter bit gave me the hunch that the reason there are no
undo's (possible) with EnableOptimizeUndo is that they are removed
similarly to how they are when you hit Cancel during (and finally
Apply) in say the Warp Brush: you cannot Redo the canceled actions,
they are removed from PSP's memory. This is what I compare to being
able to undo a script, but not to redo code that was undone and
therefore never there. It seems to me it could be that
EnableOptimizeUndo applies this rule to literally everything whether
it is needed (as with Warp contrary to Paint Brush) or not.

Uhhh... http://www.wavsurfer.com/wavs/twizone/whereis.wav

Joske
--
http://members.home.nl/j.a.c.backer/

Fabrice Roux

2006-06-03, 7:29 pm

In article <447f335c$1_3@cnews>, suzshook@adelphia.net says...
> It's SUPPOSED to work as you describe, Fabrice - a single copy of the image
> at the beginning of the script, and no further copies made. It appears as
> if perhaps the step UNDO data is still created by the individual steps, but
> then discarded at the end of the step rather than being kept when the
> EnableOptimizedScriptUndo step is included in the script. That's a memory
> savings in the long run, but costly for each step, if the data is being
> saved, especially for large images. Only Corel can tell us for sure, and
> they don't frequent these NGs. Suz

Since I'm the french guy out here I better start digging to find PSP Undo
Rosetta stone.

In order to "solve" the Undo slowdown and lockups... I did it the dumbest
way: I shoved 3Gb of RAM in my desktop computer.

I'm working with 150 megapixels panoramas. (lots of 6 megapixels images
stitched together) Believe me, between PSP 8 and 9 poor memory management
and undo system those JUMBO pictures are real PITA to process.

ps: I did tried Photoshop on some large pics... instead of slow processing
I ran into a direct Crash To Desktop. :)

--
Fabrice Roux aka [RS]Faramir_agst
PaintShop Pro and Tribes scripts
http://www.fabriceroux.com

Fabrice Roux

2006-06-03, 7:29 pm

In article <447FB923.3748F383@agabatur.xednaps>, SpRu@agabatur.xednaps
says...
> I think undo information has to be saved for each command in the
> script until the script completes because individual commands could
> be run in interactive mode and, for instance, canceled to abort a
> script part way through.

Then what I need is a 3 level EOSU:
- 0 disabled
- 1 enabled
- 2 debug/interactive

You would set the special mode 2 in rare cases where the script need to be
debuged or when the end user need to undo individual steps.

--
Fabrice Roux aka [RS]Faramir_agst
PaintShop Pro and Tribes scripts
http://www.fabriceroux.com

SuzShook

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
> SuzShook wrote:
>
> Some tools like Crop, Background Eraser, Warp, Perspective Correction,
> Straighten, Deform etc. seem to have a special state during the life
> of the tool. It is possible to undo Straighten but retain the angle
> of the annotation while you are in the Straighten tool. However, if
> you switch to another tool and come back to Straighten that angle is
> lost. Ditto of the Crop annotation and so on. However, it's hard to
> see how this would be relevant to a script that resizes and sharpens
> an image.
>
>
> I think undo information has to be saved for each command in the
> script until the script completes because individual commands could
> be run in interactive mode and, for instance, canceled to abort a
> script part way through.

I don't understand, Spandex. Why does it matter whether the script/step(s)
is/are run interactively or not. Even if the script is aborted partway
through, if it is "undone", it still returns to the pre-script state. So
what would be the point of retaining all that data? What am I missing here?
Suz
>
>
> Pure guesswork, but this might be some complexity relating to
> selective undo.

Joske

2006-06-03, 7:29 pm

SuzShook wrote:
> Joske wrote:

> 2. The EnableOptimizedScriptUndo (EOSU) command is available
> merely to reduce the amount of information a script retains. I
> believe the save information is still generated by every step,
> but is then discarded when the step terminates if EOSU is
> present. I think it's a memory-saving thing - since the script
> can only be "undone" as a whole, it's pointless to retain all
> that intermediate "undo" information, so it's discarded.

I misspelled EnableOptimizedScriptUndo in a former message.

Sure is sadly funny to see us all guess and wishing we would hear
from the programmers themselves to get to the bottom of this so that
we may understand. I know I wasted quite some time coming upon the
undo issue for the first time.

What you describe above is what I mean in both my messages by it
being similar to the Cancel in some tools, like the Warp Brush. I
described how nothing can be undone from a Cancel among a series of
steps and then an Apply.

The difference is that this method not per se helpful in a script,
as we might actually want to use an Undo command as part of it as we
could before. So my guess still (heh) stands that the code was taken
from or based on the Apply/Cancel, and not enough thought was given
to 'exceptions'.

> 4. And here's the anomaly - using the EOSU command should
> make "undoing" a script very easy, and one would think it should
> be rather instantaneous - replace the script-altered image with
> the original image saved at the outset of the script. However,
> if you've ever "undone" a long and complex script, it's not that
> simple - the system churns and churns and churns - almost, it
> seems, undoing all the steps individually! That's not what's
> supposed to be happening at all - but one wonders!

It resembles manually having to undo the steps in some tools that
use Apply when Apply was ehm... applied :-) As an aside, undoing a
script that has generated duplicate windows or copies will only undo
steps on the image that has focus, and it will not 'unmake' the
copies, nor the starter image if it was a new image made by the
script. I am not suggesting this is related to
EnableOptimizedScriptUndo (it was like this in PSP 8), but it may
say something about how scripts are undone.

In the past I have also puzzled over the 'Remove Undone Commands'
option, which if I remember has no effect anymore as I concluded. If
your theories are closer to the actual problem than mine, there may
be a clue in that also. Then again, that may be because they took
the EOSU code from Apply/Cancel.

Joske
--
http://members.home.nl/j.a.c.backer/

SuzShook

2006-06-03, 7:29 pm

Joske wrote:
> SuzShook wrote:
>
>
> I misspelled EnableOptimizedScriptUndo in a former message.
>
> Sure is sadly funny to see us all guess and wishing we would hear
> from the programmers themselves to get to the bottom of this so that
> we may understand. I know I wasted quite some time coming upon the
> undo issue for the first time.
>
> What you describe above is what I mean in both my messages by it
> being similar to the Cancel in some tools, like the Warp Brush. I
> described how nothing can be undone from a Cancel among a series of
> steps and then an Apply.
>
> The difference is that this method not per se helpful in a script,
> as we might actually want to use an Undo command as part of it as we
> could before. So my guess still (heh) stands that the code was taken
> from or based on the Apply/Cancel, and not enough thought was given
> to 'exceptions'.

You CAN still use an UNDO command in a script, and it will undo the previous
step. Just like in the original PSP 8.00 code. The difference introduced
in 8.10 was the EOSU command, which, technically said "I will not save the
useless information for script commands, because when you UNDO a script,
it's all undone anyway, back to the beginning, so the internal saves are
pointless." Scripts have always been "all or nothing" - if you undo, you
can never undo back to a certain step, but you have to undo all the way to
the beginning. I'm talking here about using Edit...Undo, or CTRL+Z undos.
Internal undo steps in a script are still allowed - but you can't have an
EOSU command at the beginning of such a script. However, if you need to
code undo steps into a script, for whatever reason, you can still insert the
EOSU step after those undo steps. It should help in a particularly long
script, especially if most of the "work" is done after those UNDO steps.
However, this is all a very GREY area, and could use some Corel input. To
that end, I've submitted a question....will share any insight I might
receive, for sure. Suz

>
>
> It resembles manually having to undo the steps in some tools that
> use Apply when Apply was ehm... applied :-) As an aside, undoing a
> script that has generated duplicate windows or copies will only undo
> steps on the image that has focus, and it will not 'unmake' the
> copies, nor the starter image if it was a new image made by the
> script. I am not suggesting this is related to
> EnableOptimizedScriptUndo (it was like this in PSP 8), but it may
> say something about how scripts are undone.
>
> In the past I have also puzzled over the 'Remove Undone Commands'
> option, which if I remember has no effect anymore as I concluded. If
> your theories are closer to the actual problem than mine, there may
> be a clue in that also. Then again, that may be because they took
> the EOSU code from Apply/Cancel.
>
> Joske

Spandex Rutabaga

2006-06-03, 7:29 pm

Joske wrote:

> Uhhh... http://www.wavsurfer.com/wavs/twizone/whereis.wav

:)

Spandex Rutabaga

2006-06-03, 7:29 pm

SuzShook wrote:

> I don't understand, Spandex. Why does it matter whether the script/step(s)
> is/are run interactively or not. Even if the script is aborted partway
> through, if it is "undone", it still returns to the pre-script state. So
> what would be the point of retaining all that data? What am I missing here?

Remember, I said I didn't have any idea about this. My thought was
that if all the individual script steps needed to be agglomerated
into one single undo state, you couldn't do that until you knew
just how many of the steps in the script would be executed. In
other words you would be writing individual step undos during
script execution until it was clear which intermediate ones could
be discarded depending on which was the actual last step of the
script. This doesn't affect restoring to the saved state prior to
the start of the script by means of undo. It does affect undoing
subsequent post-script steps to get back to the state that was the
result of the script. Again, these are the random maunderings of
a vegetable, so pay no heed.

Spandex Rutabaga

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
>
> SuzShook wrote:
>
>
> Remember, I said I didn't have any idea about this. My thought was
> that if all the individual script steps needed to be agglomerated
> into one single undo state, you couldn't do that until you knew
> just how many of the steps in the script would be executed. In
> other words you would be writing individual step undos during
> script execution until it was clear which intermediate ones could
> be discarded depending on which was the actual last step of the
> script. This doesn't affect restoring to the saved state prior to
> the start of the script by means of undo. It does affect undoing
> subsequent post-script steps to get back to the state that was the
> result of the script. Again, these are the random maunderings of
> a vegetable, so pay no heed.

I should make it clear that the above addresses your comment that:

"I believe the save information is still generated by every step,
but is then discarded when the step terminates if EOSU is present.
I think it's a memory-saving thing - since the script can only be
"undone" as a whole, it's pointless to retain all that intermediate
"undo" information, so it's discarded."

I should also make it clear that what I wrote was unmitigated
nonsense because it's the command *after* the script that causes
the post-script undo information for the script to be saved. It's
not the termination of script execution that makes this happen.
I was certainly right about the maunderings :) My apologies for
distracting you with this red herring. It's what happens when one
tries to say something on a topic about which one is profoundly
ignorant.

SuzShook

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
> Spandex Rutabaga wrote:
>
> I should make it clear that the above addresses your comment that:
>
> "I believe the save information is still generated by every step,
> but is then discarded when the step terminates if EOSU is present.
> I think it's a memory-saving thing - since the script can only be
> "undone" as a whole, it's pointless to retain all that intermediate
> "undo" information, so it's discarded."
>
> I should also make it clear that what I wrote was unmitigated
> nonsense because it's the command *after* the script that causes
> the post-script undo information for the script to be saved. It's
> not the termination of script execution that makes this happen.
> I was certainly right about the maunderings :) My apologies for
> distracting you with this red herring. It's what happens when one
> tries to say something on a topic about which one is profoundly
> ignorant.

OK - I'll go on from here. I guess I'd never thought of the step
immediately following the script as the kicker to get the script's undo
information to be saved. That makes sense though. But I'm still confused,
I think. If the image is saved at the beginning of the script (or when the
first image-altering step occurs), and EOSU is the first step of the script,
then there can be no UNDOs in the script. Therefore, why would all the
intermediate UNDo information be retained? I just ran a script that
processed 26 characters from a list. This script had the EOSU step. When I
undid the script later, I could actually watch the pulsing of the cursor as
it went through those 26 steps! If I run it on 95 characters, I can
actually count the pulses as it travels backwards through the 95 iterations
of the loop. Why is that? It almost seems as if it kept all that
information, and then had to scroll back through it to get the initial image
information to restore. If I couldn't count the pulses, I would have just
thought the system was slow. But I can actually count the pulses, and it
invariably, in this case, corresponded to the number of characters
processed. I still think running the EOSU command should make UNDOing a
script an almost instantaneous process. More random maunderings, Mr.
Veggie? Suz

Spandex Rutabaga

2006-06-03, 7:29 pm

SuzShook wrote:

> But I'm still confused, I think.

Your mistake is to believe I contribute to the reduction of
confusion as opposed to its augmentation :)

> If the image is saved at the beginning of the script (or when the
> first image-altering step occurs), and EOSU is the first step of the script,
> then there can be no UNDOs in the script.

I'm just playing with this. It is possible to conceive of a scheme
where EOSU means "discard all states of the image saved prior to
execution of each command in a script (except the first) but only
when the script completes". I don't know why things would work this
way but it would falsify your assumption.

> Therefore, why would all the
> intermediate UNDo information be retained?

As I say, it beats me.

> I just ran a script that
> processed 26 characters from a list. This script had the EOSU step. When I
> undid the script later, I could actually watch the pulsing of the cursor as
> it went through those 26 steps!

I'm going to indulge in more play. When you modify a raster image
you presumably save a rectangular area that is the bounding box
of the modified region. Retrieving this box allows undoing of a
step but avoids the memory overhead (and time) of saving the
whole image. Imagine what happens if you modify only the top left
and bottom right corner pixels of an image. Pretty inefficient
result, isn't it? Maybe what exists here is some trade-off pitting
the number of steps saved against the information saved per step
to achieve some happy compromise. Then again it may be the result
of pure incompetence, or the belief that nobody in the target
customer category would use a script even to save themselves from
death, or a consequence of a complete lack of imagination and
knowledge on my part. I vote for the last :)

SuzShook

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
> SuzShook wrote:
>
>
> Your mistake is to believe I contribute to the reduction of
> confusion as opposed to its augmentation :)
>
>
> I'm just playing with this. It is possible to conceive of a scheme
> where EOSU means "discard all states of the image saved prior to
> execution of each command in a script (except the first) but only
> when the script completes". I don't know why things would work this
> way but it would falsify your assumption.
>
>
> As I say, it beats me.
>
>
> I'm going to indulge in more play. When you modify a raster image
> you presumably save a rectangular area that is the bounding box
> of the modified region. Retrieving this box allows undoing of a
> step but avoids the memory overhead (and time) of saving the
> whole image. Imagine what happens if you modify only the top left
> and bottom right corner pixels of an image. Pretty inefficient
> result, isn't it? Maybe what exists here is some trade-off pitting
> the number of steps saved against the information saved per step
> to achieve some happy compromise. Then again it may be the result
> of pure incompetence, or the belief that nobody in the target
> customer category would use a script even to save themselves from
> death, or a consequence of a complete lack of imagination and
> knowledge on my part. I vote for the last :)

You always make me smile, SR! ;)

Joske

2006-06-03, 7:29 pm

Spandex Rutabaga wrote:
> Joske wrote:

[color=darkred]
> :)

I knew you would bite. This was an entertaining thread in more than
one aspect. Just you wait... I have been right on technical issues
on more than one occasion, you know :-)

Joske
--
http://members.home.nl/j.a.c.backer/

Joske

2006-06-03, 7:29 pm

SuzShook wrote:
> Joske wrote:
[snips just for brevity]
[color=darkred]
[color=darkred]
> However, if you need to code undo
> steps into a script, for whatever reason, you can still insert
> the EOSU step after those undo steps. It should help in a
> particularly long script, especially if most of the "work" is
> done after those UNDO steps.

Yes, back then I finally ended up doing exactly that in a script,
and it worked. Because when I read the description again it dawned
on me:

EnableOptimizedScriptUndo - Description: Allows a script to execute
faster by not saving data for sub-steps. Undo cannot be executed
from within a script once enabled.

"Once enabled".

> However, this is all a very GREY
> area, and could use some Corel input. To that end, I've
> submitted a question....will share any insight I might receive,
> for sure.

They should make these insights widely available. On more than one
occasion it takes a lot of trial and error, like the above.

Joske
--
http://members.home.nl/j.a.c.backer/

SuzShook

2006-06-03, 7:29 pm

Joske wrote:
> SuzShook wrote:
> [snips just for brevity]
>
>
>
> Yes, back then I finally ended up doing exactly that in a script,
> and it worked. Because when I read the description again it dawned
> on me:
>
> EnableOptimizedScriptUndo - Description: Allows a script to execute
> faster by not saving data for sub-steps. Undo cannot be executed
> from within a script once enabled.
>
> "Once enabled".
>
>
> They should make these insights widely available. On more than one
> occasion it takes a lot of trial and error, like the above.
>
> Joske

Unfortunately, the reply I received merely quotes from the Scripting for
Script Authors doc. No further insights . . . yet! Suz