From the documentation, the "Delay" operation seems rather innocuous,
but after reading stuff here, it seems that it opens up the
possibility of multitasking Clips.
Another aspect of multitasking would be seen in the OnClipboardChange
So it would seem possible, with enough Clips doing delays, that there
could be numerous Clips running in the background, waking up now and
then and doing things.
While too much of that would probably be more complex than most users
could handle, it did make me wonder if there is any real multitasking
going on, or if everything is truly running in one thread (simulated
And whether there is real or simulated multitasking, are there any
synchronization points? Or synchronization operations? Is there any
possibility of a Clip being interrupted anywhere except at a Delay
operation? If such a possibility exists, then synchronization
operations would be necessary; without interruptions except at Delay
points, then as long as shared variables were in a consistent state at
Delay points, and not assumed to have the same values after the Delay
points as they had before the Delay points, then it would be possible
to write reasonable "co-routines".
And regarding OnClipboardChange, that would seem to be an asynchronous
operation that would interrupt other Clips, unless it is also only
checked for when other Clips reach their end, or a Delay operation.
User actions, such as keyboard and mouse events, are also
asynchronous... experience using the product seems to indicate that
these are processed only after a long-running Clip is complete, but is
Is there any discussion of this in documentation? Any guarantees of
the order of operation, etc.?
For example, a statement like the following would clear things up (but
this is my speculation, and may not be fact):
NoteTab processes events from the Windows event queue one at a time.
Such events include mouse and keyboard actions, and Clipboard Change
notifications, and Timer events. When a Delay operation is
encountered, a Timer event is queued for it, and the Clip is suspended
from further operation. When a Clip is started, due to a mouse or
keyboard event, a Clipboard Change event, or a Timer event, it then
runs until completion, or the execution of a Delay operation, without
the possibility of other events being processed. Particularly, there
is no possibility of one Clip modifying a variable while another is
reading it, nor any possibility of a group of related variables being
seen in an inconsistent state, as long as the modifying Clip sets them
to a consistent state before ending or executing a Delay.
Some comment about Continue, Prompt, Info, and Wizards, which seem to
stall everything, would also be appropriate... It is not immediately
clear if a stalled, modal dialog (such as those, and maybe others)
would result in missing Clipboard Change events (although testing such
would give some clue).
I also wonder about discussion elsewhere on this forum about the
problem with "some programs setting the same data into the clipboard
multiple times"... and whether that could have actually been multiple
different data, with multiple Clipboard Change events queued on the
Windows event queue during a wait for user input from a modal dialog,
and then processed after the modal dialog completes? The fix
mentioned (but this stuff was old) implies that multiple Clipboard
Change events with the same data are now ignored to avoid the problem,
but wouldn't that also avoid the ability of the user actually cutting
the (apparently) same data multiple times in succession to get it seen
and processed multiple times by an OnClipboardChange Clip?
Thanks in advance for all comments and clarifications and
documentation references that are pertinent to this concept of
- notetab_is_great wrote:
>> From the documentation, the "Delay" operation seems rather
> innocuous, but after reading stuff here, it seems that it opens up
> the possibility of multitasking Clips.
> Another aspect of multitasking would be seen in the
> OnClipboardChange clip.
> So it would seem possible, with enough Clips doing delays, that
> there could be numerous Clips running in the background, waking up
> now and then and doing things.
> And regarding OnClipboardChange, that would seem to be an
> synchronous operation that would interrupt other Clips, unless it
> is also only checked for when other Clips reach their end, or a
> Delay operation.
> User actions, such as keyboard and mouse events, are also
> asynchronous... experience using the product seems to indicate that
> these are processed only after a long-running Clip is complete, but
> is that guaranteed?
This is how I understand clip processing.
Forget multi-tasking, NoteTab executes clips sequentially or serially.
It does however work very quickly.
Clip processing stops for the duration of a ^!Delay, and branching halts
the current clip until the branch completes and control returns to the
initial clip on the succeeding line.
OnClipBoardChange is just another form of branch, no multi-tasking involved.
2007.02.01 - 19.43.10
"Wearing Outfits You Already Have."
¤ hrs ø hsavage@...