Loading ...
Sorry, an error occurred while loading the content.

multitasking Clips

Expand Messages
  • notetab_is_great
    Hi, From the documentation, the Delay operation seems rather innocuous, but after reading stuff here, it seems that it opens up the possibility of
    Message 1 of 2 , Feb 1, 2007
    • 0 Attachment
      Hi,

      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.

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

      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
      that guaranteed?

      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
      multitasking Clips.
    • hsavage
      ... perl, This is how I understand clip processing. Forget multi-tasking, NoteTab executes clips sequentially or serially. It does however work very quickly.
      Message 2 of 2 , Feb 1, 2007
      • 0 Attachment
        notetab_is_great wrote:
        > Hi,
        >
        >> 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?

        perl,

        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.

        ºvº SL-2-3
        2007.02.01 - 19.43.10

        Classic Clothing:
        "Wearing Outfits You Already Have."

        ¤ hrs ø hsavage@...
      Your message has been successfully submitted and would be delivered to recipients shortly.