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

Re: functional, but dysfunctional also onclipboardchange

Expand Messages
  • notetab_is_great
    Alan, Thanks for your response. I m glad to know that %^EMPTY% is for documentation or special purposes, but that can also do the job. ... Below is a
    Message 1 of 19 , Feb 3, 2007
    • 0 Attachment
      Alan,

      Thanks for your response. I'm glad to know that %^EMPTY% is for
      documentation or special purposes, but that "" can also do the job.


      > Your functional but dysfunctional was running two clips at once (or
      > attempting to do so). AFAIK running two clips at once in Notetab is
      > not supported.


      Below is a revised library that demonstrates up to 6 concurrent clips
      running: manually invoke, a few seconds apart, donothing1, donothing2,
      donothing3, and donothing4 in that order. Then invoke bar. Then put
      something on the clipboard. That is a total of 6 clips running
      concurrently, and bar succeeds, providing that OnClipboardChange also
      succeeds. And watching the status bar long enough (90 seconds from
      when you started) will demonstrate that the other clips were still
      there, successfully.

      So it isn't the number of concurrent clips, but apparently something
      else, that causes the problems. My best guess so far is nested clips,
      but I suppose it could be something else. But why should nested clips
      cause more problem than concurrent clips?

      To show that it is nested clips, try the following sequence: Invoke
      in the sequence donothing1, donothing2, donothing3invoker, donothing4

      Surprise! donothing4 won't invoke, it beeps. That is true even if
      OnClipboardChange is removed or renamed. So it seems that Delay only
      allows other clips to run if the Delay is invoked from an unnested
      Clip invocation :( That is a severe limitation on building modular code.


      > The next code in a library works via bar2 (^!Clip bar2)
      (clip code clipped)

      Yes, you've come up with an alternate scheme that works... but
      reworking it that way seems like it would require much more complexity
      for my complete application (my postings are just a small piece of my
      plans). I may have to go that route, though.


      Here's my demonstration of concurrent clips.


      = V5 MultiLine NoSorting TabWidth=30

      H=OnClipboardChange
      ; do nothing, if there is no variable to set
      ^!if "^%p_GrabClip%" = "" end
      ; set the variable whose name is in %p_GrabClip%
      ^!Set %^%p_GrabClip%%=^$GetClipboard$
      ; so that the variable is only set once, and we go back to doing nothing
      ^!Set %p_GrabClip%=""

      H=bar
      ; test case for the above... wait for one Clipboard change
      ^!Set %var%=""
      ^!Set %p_GrabClip%=var
      ^!StatusShow Waiting for value
      ^!Delay 1
      ^!IfSame "^%var%" "" Skip_-1
      ; display the results. Looks good.
      ^!Info var=^%var%

      H=bar2
      ^!Clip bar

      H=donothing1
      ; runs forever, until Ctrl+Alt terminates it
      ^!SetHintInfo Yep, I'm doing nothing 1
      ^!Delay 800
      ^!SetHintInfo Yep, I'm doing nothing 1
      ^!Delay 100

      H=donothing2
      ; runs forever, until Ctrl+Alt terminates it
      ^!SetHintInfo Yep, I'm doing nothing 2
      ^!Delay 600
      ^!SetHintInfo Yep, I'm doing nothing 2
      ^!Delay 100

      H=donothing3
      ; runs forever, until Ctrl+Alt terminates it
      ^!SetHintInfo Yep, I'm doing nothing 3
      ^!Delay 400
      ^!SetHintInfo Yep, I'm doing nothing 3
      ^!Delay 100

      H=donothing4
      ; runs forever, until Ctrl+Alt terminates it
      ^!SetHintInfo Yep, I'm doing nothing 4
      ^!Delay 100
      ^!SetHintInfo Yep, I'm doing nothing 4
      ^!Delay 100

      H=donothing3invoker
      ^!Clip donothing3
    • Alan
      (There seems to be not yet achieved sufficient communication so as to convey a correct understanding about the important distinction between 1. to *launch* a
      Message 2 of 19 , Feb 3, 2007
      • 0 Attachment
        (There seems to be not yet achieved sufficient communication so as to convey a
        correct understanding about the important distinction between 1. to *launch*
        a 2nd (or 3rd, etc.) clip while a clip is already currently
        running --*versus*-- 2. the use of ^!Clip

        # 1 and # 2 are different. # 2 is *not* (not in actuality) *launching*
        another clip while a clip is already running. Instead, what # 2 is doing is
        it is "farming out" (or contracting to) (or, even better yet, "routing the
        processing to").

        Continued further below is that ^!Clip, however many times it is used, is to
        be seen as a conglomeration of clips that in actuality are esentially they
        are united as one huge clip. The point is that, since ^!Clip is for "routing
        the processing to", it is only one clip that is running no matter how many
        times ^!Clip is used.

        On Saturday 03 February 2007 00:53, notetab_is_great wrote:
        <snip>
        > Below is a revised library that demonstrates up to 6 concurrent clips
        > running: manually invoke, a few seconds apart, donothing1, donothing2,
        > donothing3, and donothing4 in that order. Then invoke bar. Then put
        > something on the clipboard. That is a total of 6 clips running
        > concurrently, and bar succeeds, providing that OnClipboardChange also
        > succeeds. And watching the status bar long enough (90 seconds from
        > when you started) will demonstrate that the other clips were still
        > there, successfully.

        Are you trying to use clip as a programming language? It is not. It is a
        macro language (a powerful macro language). Notetab is a text editor that
        you can write clips/macros so as to "program (or automate repetitive tasks
        in) the editor".

        But clip itself is *definitely not* a programming language. A "programable
        editor" is a term I've heard used about Notetab. But it is a macro language
        that is used to achieve this automation or so called "programability" of the
        editor.

        Oh, clip has likeness to, say, qbasic. I guess qbasic is considered as a
        programming language. But clip is definitely macros language.
        --

        It *appears* to me that I've not yet *effectively* *totally* communicated
        to/with you.

        I've no argument with you that your well made point quoted up
        above "absolutely won't work".

        But, once again (as per your lib below) and your well made point quoted up
        above, you are *launching* a second (and 3rd, etc.) clip while another clip
        is still running. And, AFAIK when a clip is running, it is not supported to
        *launch* a 2nd clip (nor a 3rd, etc.) so that now two clips are running
        simultaneously.

        s/concurrently/simultaneously/; # perl substitution lingo

        I'm using the term "simultaneously" to replace or in place of concurrently
        term that you used.

        AFAIK it is not supported in Notetab to launch/run two clips *simultaneously*.
        That's not to say that sometimes it won't at least partially work or work
        under some circumstances but not others.

        A Very *Important* distinction: If by "nested" you mean what I call parent and
        child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
        simultaneously running more than one clip at once.

        Instead, proceesing goes along here in linear fashion. ^!Clip merely
        *directs* the processing to what I call a child clip. Once processing is
        done/exhausted in that child clip then the processing returns/continues with
        the very next line after the ^!Clip line in the parent clip.

        I've no argument about "nested".

        But my point here is that ^!Clip clip_name is a way to have what I might
        call "parent and child *portions of the same clip*"

        IOW when ^!Clip is used, Notetab sees however many nested of these as one
        clip.

        (it's an alternative to having one great big huge clip -- IOW the ^!Clip
        divided up clips should be considered as overall they are the one great big
        huge clip because this is how Notetab treats/handles this scenario in fashion
        whereby "only one clip is running") -- as I said, it's a way to route the
        processing.

        So, ^!Clip is a way to section off or divide up processing tasks via "chunks"
        of code. Also, when used at multi levels of depth (grandparent, parent,
        child), ^!Clip can be used for levels of (I suppose "nested") depth so as for
        processing to only go down to the lower most levels only when certain
        circumstances are met.

        So as to illustrate the "nested" and "levels":

        Mr. Fookes, the author of Notetab, wrote the next clip library:

        http://www.notetab.com/pad/index.htm

        On that page, you can download the pad clip library. I suggest/offer that you
        download that library and look at it.

        I've yet to discover how many levels deep of "nested" (multi levels useage of
        ^!Clip) are in it. In my trying to grasp it (the entirety of the library's
        operations) IOW for me to *map* (access the how of) (have a map for myself of
        what does what and when it does it along the way) how it does what it does, I
        formerly *got lost* at somewhere near 3 to 4 levels deep.

        I wonder if Mr. Fookes has something that we don't know about such as "tags"
        for clips?

        And/or, maybe I've not yet experimented enough with ^!SetDebug ON ??

        (The C programming language has ctags for a programmer to help track/know what
        does what and when it does it along the way)

        <snip>
        > Here's my demonstration of concurrent clips.

        My term for it is: "simultaneously running" clips (as per your useage
        instructions for them that are quoted/enclosed up above in this email).
        AFAIK, a *bonus* *if* it even works at all -- let alone whether or not it
        works under more complex circumstances. AFAIK what's supported is only 1
        clip running at a time, not 2 or 3 etc. clips launched and running at the
        *same* time.

        > = V5 MultiLine NoSorting TabWidth=30
        >
        > H=OnClipboardChange
        > ; do nothing, if there is no variable to set
        > ^!if "^%p_GrabClip%" = "" end
        > ; set the variable whose name is in %p_GrabClip%
        > ^!Set %^%p_GrabClip%%=^$GetClipboard$
        > ; so that the variable is only set once, and we go back to doing nothing
        > ^!Set %p_GrabClip%=""
        >
        > H=bar
        > ; test case for the above... wait for one Clipboard change
        > ^!Set %var%=""
        > ^!Set %p_GrabClip%=var
        > ^!StatusShow Waiting for value
        > ^!Delay 1
        > ^!IfSame "^%var%" "" Skip_-1
        > ; display the results. Looks good.
        > ^!Info var=^%var%
        >
        > H=bar2
        > ^!Clip bar
        >
        > H=donothing1
        > ; runs forever, until Ctrl+Alt terminates it
        > ^!SetHintInfo Yep, I'm doing nothing 1
        > ^!Delay 800
        > ^!SetHintInfo Yep, I'm doing nothing 1
        > ^!Delay 100
        >
        > H=donothing2
        > ; runs forever, until Ctrl+Alt terminates it
        > ^!SetHintInfo Yep, I'm doing nothing 2
        > ^!Delay 600
        > ^!SetHintInfo Yep, I'm doing nothing 2
        > ^!Delay 100
        >
        > H=donothing3
        > ; runs forever, until Ctrl+Alt terminates it
        > ^!SetHintInfo Yep, I'm doing nothing 3
        > ^!Delay 400
        > ^!SetHintInfo Yep, I'm doing nothing 3
        > ^!Delay 100
        >
        > H=donothing4
        > ; runs forever, until Ctrl+Alt terminates it
        > ^!SetHintInfo Yep, I'm doing nothing 4
        > ^!Delay 100
        > ^!SetHintInfo Yep, I'm doing nothing 4
        > ^!Delay 100
        >
        > H=donothing3invoker
        > ^!Clip donothing3
        ; end

        --
        Alan.
      • hsavage
        ... WordWeb s definition of concurrent. concurrent = Occurring or operating at the same time Although you initialize these DoNothing? clips they are not
        Message 3 of 19 , Feb 3, 2007
        • 0 Attachment
          notetab_is_great wrote:
          >
          > Below is a revised library that demonstrates up to 6 concurrent
          > clips running: manually invoke, a few seconds apart, donothing1,
          > donothing2, donothing3, and donothing4 in that order. Then invoke
          > bar. Then put something on the clipboard. That is a total of 6
          > clips running concurrently, and bar succeeds, providing that
          > OnClipboardChange also succeeds. And watching the status bar long
          > enough (90 seconds from when you started) will demonstrate that the
          > other clips were still there, successfully.

          WordWeb's definition of concurrent.
          concurrent = Occurring or operating at the same time

          Although you initialize these 'DoNothing?' clips they are not running
          concurrently, they are running serially, in tandem, one after another.

          You can discover that by watching the NoteTab status line. The clips
          will run 'last in, first out' order.

          The delays will time out in the last clip then the next most recent clip
          will start timing.

          I believe if you tried this using language to do any actual work NoteTab
          would 'Error' out. It isn't built for concurrent multi-tasking.

          > So it isn't the number of concurrent clips, but apparently
          > something else, that causes the problems. My best guess so far is
          > nested clips, but I suppose it could be something else. But why
          > should nested clips cause more problem than concurrent clips?

          By 'nested' I suppose you mean clips that are started with a ^!Clip
          command within the body of the currently running clip. If so, I use
          nested clips all the time and have no trouble with them.

          > Surprise! donothing4 won't invoke, it beeps. That is true even if
          > OnClipboardChange is removed or renamed. So it seems that Delay
          > only allows other clips to run if the Delay is invoked from an
          > unrested Clip invocation :( That is a severe limitation on
          > building modular code.

          I had no trouble with 'DoNothing4' beeping, it worked exactly like the
          first 3 clips.

          You may possibly be running into a dearth of resources, NoteTab requires
          a lot of ram, some of the commands/functions are more ram intensive than
          others.

          I thought I knew what you were striving for at one time, to use
          'OnClipBoardChange' and have an independent ^!StatusShow of an action to
          be taken, but, I must admit I have no clue at this point.

          ºvº SL-2-9
          2007.02.03 - 16.40.53

          Great Truth About Growing Old:
          "Forget the health food. I need all the preservatives I can get."

          ¤ hrs ø hsavage@...
        • notetab_is_great
          ... to convey a ... *launch* ... Commmunication is the hardest part about computers... knowing what the other fellow is saying so we comprehend and learn...
          Message 4 of 19 , Feb 3, 2007
          • 0 Attachment
            --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
            >
            > (There seems to be not yet achieved sufficient communication so as
            to convey a
            > correct understanding about the important distinction between 1. to
            *launch*
            > a 2nd (or 3rd, etc.) clip while a clip is already currently
            > running --*versus*-- 2. the use of ^!Clip


            Commmunication is the hardest part about computers... knowing what the
            other fellow is saying so we comprehend and learn...


            >
            > # 1 and # 2 are different. # 2 is *not* (not in actuality)
            *launching*
            > another clip while a clip is already running. Instead, what # 2 is
            doing is
            > it is "farming out" (or contracting to) (or, even better yet,
            "routing the
            > processing to").


            I think we agree on the difference between #1 and #2. #1, launching
            another clip while a clip is running, produces clips that appear to be
            running simultaneously. #2, using ^!Clip, which I call "nested
            clips", do not produce, and are not expected to produce, simultaneous
            execution: the ^!Clip operation suspends the first clips, performs the
            clip named as a parameter, and when that one completes, the first
            resumes at the next instruction.


            As far as I can determine, OnClipboardChange is a 2nd way, besides the
            user explicitly launching a clip, for a clip to be initiated. If
            other unnested-Clips are already running, it seems that
            OnClipboardChange can be successfully launched during ^!Delay
            operations in those other clips' operation sequence. But if any
            nested clip is currently running, then OnClipboardChange produces a
            beep, just like the user attempting to launch another clip while a
            nested clip is currently running.


            >
            > Continued further below is that ^!Clip, however many times it is
            used, is to
            > be seen as a conglomeration of clips that in actuality are
            esentially they
            > are united as one huge clip. The point is that, since ^!Clip is for
            "routing
            > the processing to", it is only one clip that is running no matter
            how many
            > times ^!Clip is used.


            When not thinking about simultaneous clips, your "united as one huge
            clip" comment is a reasonable interpretation of the matter, but when
            thinking about simultaneous clips, then there is a visible distinction.

            Initiation of donothing3 directly (one huge clip) does not prevent
            initiation of donothing4. Initiation of donothing3invoker, which has
            exactly the same set of operations as donothing3 because it calls it,
            does prevent initiation of donothing4, which proves there is a
            distinction between "one huge clip", and "united as one huge clip".



            > Are you trying to use clip as a programming language? It is not.
            It is a
            > macro language (a powerful macro language). Notetab is a text
            editor that
            > you can write clips/macros so as to "program (or automate repetitive
            tasks
            > in) the editor".


            In my computer science classes, I learned that a functional computer
            can be created from two instructions: subtract, and branch if
            negative. For example, negation can be synthesized by subtracting
            from 0, addition can be synthesized by negating and subtracting,
            multiplication is a series of additions, etc. So I find that NoteTab
            supports subtract [ ^!Set %x%=^$Calc(^%x%-^%y%)$ ] and branch if
            negative [ ^!If ^%x% < 0 Skip_-3 ], so I conclude that it is a
            programming language. To me, a macro language is simply a linear
            sequence of operations, like a tape recorder/player. Once control
            flow and arithmetic are added to a macro language, it becomes a
            programming language.


            > But clip itself is *definitely not* a programming language. A
            "programable
            > editor" is a term I've heard used about Notetab. But it is a macro
            language
            > that is used to achieve this automation or so called
            "programability" of the
            > editor.
            >
            > Oh, clip has likeness to, say, qbasic. I guess qbasic is considered
            as a
            > programming language. But clip is definitely macros language.
            > --


            So we disagree about what to call the clip language...


            > It *appears* to me that I've not yet *effectively* *totally*
            communicated
            > to/with you.
            >
            > I've no argument with you that your well made point quoted up
            > above "absolutely won't work".
            >
            > But, once again (as per your lib below) and your well made point
            quoted up
            > above, you are *launching* a second (and 3rd, etc.) clip while
            another clip
            > is still running. And, AFAIK when a clip is running, it is not
            supported to
            > *launch* a 2nd clip (nor a 3rd, etc.) so that now two clips are running
            > simultaneously.
            >
            > s/concurrently/simultaneously/; # perl substitution lingo
            >
            > I'm using the term "simultaneously" to replace or in place of
            concurrently
            > term that you used.
            >
            > AFAIK it is not supported in Notetab to launch/run two clips
            *simultaneously*.
            > That's not to say that sometimes it won't at least partially work or
            work
            > under some circumstances but not others.


            You likely have more experience with NoteTab/clip than I do, so I'm
            not going to disagree with anything you say here... but I would like
            to make some terminology definitions so we can communicate better.

            1) documented: a feature that is explained in the documentation.
            Generally all documented features are also supported (see below).

            2) supported: a feature that is claimed to work by the purveyor of the
            product. Generally all supported features are also documented, but
            sometimes older features, while still supported, are dropped from the
            documentation in favor of newer, better features that encompass all
            the capability of the older feature, and sometimes the documentation
            of new features lags the development of the feature and its delivery
            in the product.

            3) bonus: a feature that is not documented or supported, but which, by
            experimentation, is found to work. There is no guarantee that such a
            feature will work in future versions of the product.


            > A Very *Important* distinction: If by "nested" you mean what I call
            parent and
            > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
            > simultaneously running more than one clip at once.


            I agree; and that is why I was surprised to discover that nested
            clips, which you call parent/child clips, prevent the simultaneous
            invocation of other clips, whereas "one huge clip" does not, even if
            they have the same sequence of operations.


            > So as to illustrate the "nested" and "levels":
            >
            > Mr. Fookes, the author of Notetab, wrote the next clip library:
            >
            > http://www.notetab.com/pad/index.htm
            >
            > On that page, you can download the pad clip library. I
            suggest/offer that you
            > download that library and look at it.


            Yes, a very complex program.


            > I wonder if Mr. Fookes has something that we don't know about such
            as "tags"
            > for clips?


            Understanding such a complex program can often be better done by
            looking at the individual building blocks, and understanding them
            first... but I have no idea what tools Mr. Fookes might have for
            building clip libraries.


            > AFAIK, a *bonus* *if* it even works at all -- let alone whether or
            not it
            > works under more complex circumstances. AFAIK what's supported is
            only 1
            > clip running at a time, not 2 or 3 etc. clips launched and running
            at the
            > *same* time.


            So your theory is that simultaneous clips are a bonus feature.
            Certainly I couldn't find documentation for them, so they don't seem
            to be a documented feature.

            Yet Jody seems to write clips that use the feature, and so do others
            on this board. So it seems to be an acceptable use, perhaps it might
            be a supported feature, but it could be a well-used bonus feature.

            Can anyone declare that simultaneous clips are a bonus feature? What
            are the chances of them being removed, deprecated, or enhanced,
            respectively, in future version of NoteTab?

            If I build clips that depend on them, are they likely to continue working?

            Are there other limits that are likely to surface as clip complexity
            increases?
          • notetab_is_great
            ... I understand that it is extremely likely that multiple operating system threads/CPUs are not used to cause true concurrency. And I understand the how
            Message 5 of 19 , Feb 3, 2007
            • 0 Attachment
              --- In ntb-clips@yahoogroups.com, hsavage <hsavage@...> wrote:
              >
              >
              > notetab_is_great wrote:
              > >
              > > Below is a revised library that demonstrates up to 6 concurrent
              > > clips running: manually invoke, a few seconds apart, donothing1,
              > > donothing2, donothing3, and donothing4 in that order. Then invoke
              > > bar. Then put something on the clipboard. That is a total of 6
              > > clips running concurrently, and bar succeeds, providing that
              > > OnClipboardChange also succeeds. And watching the status bar long
              > > enough (90 seconds from when you started) will demonstrate that the
              > > other clips were still there, successfully.
              >
              > WordWeb's definition of concurrent.
              > concurrent = Occurring or operating at the same time
              >
              > Although you initialize these 'DoNothing?' clips they are not running
              > concurrently, they are running serially, in tandem, one after another.


              I understand that it is extremely likely that multiple operating
              system threads/CPUs are not used to cause true concurrency. And I
              understand the how multitasking on a single thread of control can be
              done. What I am trying to figure out is where the limits of
              multitasking are in the clip programming language.

              I understand that OnClipboardChange, ^!TimerPlay/^!TimerStart, and
              user invocation are the 3 asynchronous ways of initiating a clip. I
              understand that ^!Delay (and are there other such operations?) can
              suspend an unnested clip in such a manner that other clips can be
              invoked in a manner that appears like multitasking.


              > You can discover that by watching the NoteTab status line. The clips
              > will run 'last in, first out' order.
              >
              > The delays will time out in the last clip then the next most recent
              clip
              > will start timing.


              The delays seem to run concurrently. Check your watch from starting
              donothing1 until it completes, whether or not you invoke other
              donothingX clips in the meantime.


              > I believe if you tried this using language to do any actual work
              NoteTab
              > would 'Error' out. It isn't built for concurrent multi-tasking.


              I appreciate your response, and your experience with NoteTab, that has
              led you to your belief system about clips. I'm trying to get past
              belief systems, though, and understand exactly what capabilities are
              provided. It is documented that recursive clips are not supported.


              > > So it isn't the number of concurrent clips, but apparently
              > > something else, that causes the problems. My best guess so far is
              > > nested clips, but I suppose it could be something else. But why
              > > should nested clips cause more problem than concurrent clips?
              >
              > By 'nested' I suppose you mean clips that are started with a ^!Clip
              > command within the body of the currently running clip. If so, I use
              > nested clips all the time and have no trouble with them.


              Yes, that is what I mean by nested clips. And yes, they seem to work
              fine, when not also dealing with multitasking clips.

              But it seems that ^!Delay in a non-nested clip provides more ability
              to multitask clips than ^!Delay in a nested clip, which seems to block
              the ability to start another multitasking clip.


              > > Surprise! donothing4 won't invoke, it beeps. That is true even if
              > > OnClipboardChange is removed or renamed. So it seems that Delay
              > > only allows other clips to run if the Delay is invoked from an
              > > unrested Clip invocation :( That is a severe limitation on
              > > building modular code.
              >
              > I had no trouble with 'DoNothing4' beeping, it worked exactly like the
              > first 3 clips.


              I think you missed the difference in the two invocation sequences I
              was suggesting. Invoking donothing3 and then donothing4 works.
              Invoking donothing3invoker and then donothing4 beeps.


              > You may possibly be running into a dearth of resources, NoteTab
              requires
              > a lot of ram, some of the commands/functions are more ram intensive
              than
              > others.


              Only if NoteTab artificially limits the available resources. My
              machine is quite capable.


              > I thought I knew what you were striving for at one time, to use
              > 'OnClipBoardChange' and have an independent ^!StatusShow of an
              action to
              > be taken, but, I must admit I have no clue at this point.


              Yes, you did understand my goal. But my sample clips that have been
              posted are extremely limited, compared to my plans. When I discovered
              that nested clips and non-nested clips seem to differ in their ability
              to invoke ^!Delay and allow multitasking clips to be initiated, I
              created a sub-goal of attempting to understand the multitasking
              features of NoteTab in more depth, hopefully to discover if other such
              limits exist, before wasting a lot of time coding things that will not
              work.

              Presently, it appears that code must be structured so that ^!Delay
              operations are in non-nested clips, although nested clips can be
              called before or after the ^!Delay operation. This forces code to be
              designed differently than otherwise.

              Presently, it appears that OnClipboardChange, if it gets invoked at a
              time when all the multitasking clips are in non-nested ^!Delays, can
              successfully use as many nested clips of its own as it desires.

              Left to determine are whether there are other operations that wait for
              user input or timers (^!Delay waits for a timer, and if invoked from a
              nested clip, blocks multitasking clip initiation) that will block or
              otherwise confuse multitasking clips.

              >
              > ºvº SL-2-9
              > 2007.02.03 - 16.40.53
              >
              > Great Truth About Growing Old:
              > "Forget the health food. I need all the preservatives I can get."
              >
              > ¤ hrs ø hsavage@...
              >
            • Alan
              (I just saw your reply to Harvey - so I thought I d mention this it s the truth) BTW, my opining is based upon my experience of writing and using clips and
              Message 6 of 19 , Feb 3, 2007
              • 0 Attachment
                (I just saw your reply to Harvey - so I thought I'd mention this it's the
                truth) BTW, my "opining" is based upon my experience of writing and using
                clips and years of following this clips list and that I'm a very highly
                mechanical aptitude person. IOW, I choose not to believe the help file, and
                I "hack like crazy" and if I can make it work reliably then I'll use it. I
                certainly do not have firm belief systems of what I limit myself to that
                consists of what will and what will not work. To resolve something, I
                usually hack code until I get something to work (in addition to considering
                what others offer and considering the documentation/help).

                On Saturday 03 February 2007 15:32, notetab_is_great wrote:
                > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
                > > (There seems to be not yet achieved sufficient communication so as

                <snipped, 1. launch two clips in fashion whereby these two are "simultaneous
                execution/running versus 2. ^!Clip and how it operates.>

                > I think we agree on the difference between #1 and #2. #1, launching
                > another clip while a clip is running, produces clips that appear to be
                > running simultaneously. #2, using ^!Clip, which I call "nested
                > clips", do not produce, and are not expected to produce, simultaneous
                > execution: the ^!Clip operation suspends the first clips, performs the
                > clip named as a parameter, and when that one completes, the first
                > resumes at the next instruction.

                Yes.

                > As far as I can determine, OnClipboardChange is a 2nd way, besides the
                > user explicitly launching a clip, for a clip to be initiated.

                Yes.

                > If
                > other unnested-Clips are already running, it seems that
                > OnClipboardChange can be successfully launched during ^!Delay
                > operations in those other clips' operation sequence. But if any
                > nested clip is currently running, then OnClipboardChange produces a
                > beep, just like the user attempting to launch another clip while a
                > nested clip is currently running.

                This is where I opine (my useage of AFAIK) that it is a bonus if 2
                simultaneously execution/running clips might happen to work.

                <snipped "chunk (divided up pieces of) coding via the use of ^!Clip versus
                what I've opined as the alternative which is to have "one huge clip">

                > When not thinking about simultaneous clips, your "united as one huge
                > clip" comment is a reasonable interpretation of the matter, but when
                > thinking about simultaneous clips, then there is a visible distinction.
                >
                > Initiation of donothing3 directly (one huge clip) does not prevent
                > initiation of donothing4. Initiation of donothing3invoker, which has
                > exactly the same set of operations as donothing3 because it calls it,
                > does prevent initiation of donothing4, which proves there is a
                > distinction between "one huge clip", and "united as one huge clip".

                I've absolutely no argument with you whatsover about your call there on
                *distinction* . My point, however, is that I opine that such distinction
                exactly as that is attributed to an offshoot of that you are operating under
                a bonus condition and that the bonus is setting the stage for this to happen.

                Once again, I opine that this scenario you mentioned occurs in this fashion to
                you due to what I've termed/opined the bonus of if 2 simultaneous
                executed/running clips might happen to work.

                > In my computer science classes, I learned that a functional computer
                > can be created from two instructions: subtract, and branch if
                > negative. For example, negation can be synthesized by subtracting

                You lost me. Went over my head. That's ok.

                > So we disagree about what to call the clip language...

                Fine. All I know is I got it from Jody that to write a clip is to write a
                macro. And it appears that this came from Mr. Fookes to Jody though I've no
                absolute certainty of this latter.

                I suspect that there might be others who would agree with me. But I doubt
                that this matters. I only asked you because your coding style seemed to me
                to be "programmer like" ie the use of Notetab's perhaps a bit cursory multi
                level or variable within a variable syntax.

                > You likely have more experience with NoteTab/clip than I do, so I'm
                > not going to disagree with anything you say here... but I would like
                > to make some terminology definitions so we can communicate better.
                >
                > 1) documented: a feature that is explained in the documentation.
                > Generally all documented features are also supported (see below).
                >
                > 2) supported: a feature that is claimed to work by the purveyor of the
                > product. Generally all supported features are also documented, but
                > sometimes older features, while still supported, are dropped from the
                > documentation in favor of newer, better features that encompass all
                > the capability of the older feature, and sometimes the documentation
                > of new features lags the development of the feature and its delivery
                > in the product.
                >
                > 3) bonus: a feature that is not documented or supported, but which, by
                > experimentation, is found to work. There is no guarantee that such a
                > feature will work in future versions of the product.

                Agreed on all 3 with one exception. The exception is that (once again, I
                opine) that in some places the help/documentation is terse. And, it is
                enough so that people come to these lists asking for further and usually more
                specific of "in the help/doc, what does it mean by (thus_and_such)".

                > > A Very *Important* distinction: If by "nested" you mean what I call
                > > parent and
                > > child clips (where ^!Clip clip_name is used) -- to do so, this is *not*
                > > simultaneously running more than one clip at once.
                >
                > I agree; and that is why I was surprised to discover that nested
                > clips, which you call parent/child clips, prevent the simultaneous
                > invocation of other clips, whereas "one huge clip" does not, even if
                > they have the same sequence of operations.

                I opine, attribute this to being "in a so called bonus" sets the stage (bonus
                being the prelude to whatever)

                > So your theory is that simultaneous clips are a bonus feature.
                > Certainly I couldn't find documentation for them, so they don't seem
                > to be a documented feature.
                >
                > Yet Jody seems to write clips that use the feature, and so do others
                > on this board. So it seems to be an acceptable use, perhaps it might
                > be a supported feature, but it could be a well-used bonus feature.

                I myself have certainly not known that this is "well used"

                I would tend to think that it has not been used very much. I've not seen it
                in use very much if at all.

                One thing I do know, however, is that if it can work, people will use it.
                I've seen almost anything and everything. So, I'm not surprised that you
                have argument material against my mentioned herein opine of bonus.

                > Can anyone declare that simultaneous clips are a bonus feature? What
                > are the chances of them being removed, deprecated, or enhanced,
                > respectively, in future version of NoteTab?
                >
                > If I build clips that depend on them, are they likely to continue working?
                >
                > Are there other limits that are likely to surface as clip complexity
                > increases?

                notetab_is_great, I sincerely wish you good luck and happiness in all of your
                endeavors.

                --
                Alan.
              • notetab_is_great
                ... it s the ... using ... file, and ... it. I ... that ... considering ... Sounds like a good process to me :) But the documentation can be helpful (though
                Message 7 of 19 , Feb 3, 2007
                • 0 Attachment
                  --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
                  >
                  > (I just saw your reply to Harvey - so I thought I'd mention this
                  it's the
                  > truth) BTW, my "opining" is based upon my experience of writing and
                  using
                  > clips and years of following this clips list and that I'm a very highly
                  > mechanical aptitude person. IOW, I choose not to believe the help
                  file, and
                  > I "hack like crazy" and if I can make it work reliably then I'll use
                  it. I
                  > certainly do not have firm belief systems of what I limit myself to
                  that
                  > consists of what will and what will not work. To resolve something, I
                  > usually hack code until I get something to work (in addition to
                  considering
                  > what others offer and considering the documentation/help).


                  Sounds like a good process to me :) But the documentation can be
                  helpful (though terse), in the areas in which it chooses to be. It is
                  nice, for example, not to have to try strange combinations of
                  characters after ^! to discover what operations are available...
                  although maybe we could discover some great features that way!


                  > > Yet Jody seems to write clips that use the feature, and so do others
                  > > on this board. So it seems to be an acceptable use, perhaps it might
                  > > be a supported feature, but it could be a well-used bonus feature.
                  >
                  > I myself have certainly not known that this is "well used"
                  >
                  > I would tend to think that it has not been used very much. I've not
                  seen it
                  > in use very much if at all.
                  >
                  > One thing I do know, however, is that if it can work, people will
                  use it.
                  > I've seen almost anything and everything. So, I'm not surprised
                  that you
                  > have argument material against my mentioned herein opine of bonus.


                  Well, sometimes you see what you look for... it is hard to say how
                  much use multitasking clips have gotten, but certainly it seems that
                  they have gotten some use, because there is discussion about having
                  clips that sit in the background and do things, and how to end them
                  "typically by watching for Shift+Alt" and a couple coding conventions
                  for detecting that combination.


                  > > Can anyone declare that simultaneous clips are a bonus feature? What
                  > > are the chances of them being removed, deprecated, or enhanced,
                  > > respectively, in future version of NoteTab?
                  > >
                  > > If I build clips that depend on them, are they likely to continue
                  working?
                  > >
                  > > Are there other limits that are likely to surface as clip complexity
                  > > increases?
                  >
                  > notetab_is_great, I sincerely wish you good luck and happiness in
                  all of your
                  > endeavors.


                  Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
                  the forums, and comments. Seems the knowledge on this topic is quite
                  limited (only a few responders, with only experimental knowledge (like
                  mine, but mine is based on very limited experience so far))... so a
                  few comments from Mr. Fookes might be extremely enlightening.
                • Alan
                  ... ... I ve seen and contributed to posts/threads like that, searchable in the archives of this the ntb-clips list at Yahoo Groups. But most of them
                  Message 8 of 19 , Feb 3, 2007
                  • 0 Attachment
                    On Saturday 03 February 2007 18:19, notetab_is_great wrote:
                    > --- In ntb-clips@yahoogroups.com, Alan <acummingsus@...> wrote:
                    <snip>
                    > Well, sometimes you see what you look for... it is hard to say how
                    > much use multitasking clips have gotten, but certainly it seems that
                    > they have gotten some use, because there is discussion about having
                    > clips that sit in the background and do things, and how to end them
                    > "typically by watching for Shift+Alt" and a couple coding conventions
                    > for detecting that combination.

                    I've seen and contributed to posts/threads like that, searchable in the
                    archives of this the ntb-clips list at Yahoo Groups.

                    But most of them would be about how to put a clip into a repetitively looping
                    mode while the user does something else, gathers what to input, or etc. And
                    then using one of the control sequences of keyboard keys (you mentioned the
                    shift+alt) (there are two others for a total of three available) to get the
                    clip to do some action, either bring up a prompt for user input or resume
                    processing somewhere or exit/end the clip. Outside of that, I'm not aware of
                    any that loop repetitively, awaiting a signal of some sort so as to launch a
                    2nd clip while this clip continues to run.

                    > Thanks Alan, I wonder if Mr. Fookes ever reads any of this stuff, on
                    > the forums, and comments. Seems the knowledge on this topic is quite
                    > limited (only a few responders, with only experimental knowledge (like
                    > mine, but mine is based on very limited experience so far))... so a
                    > few comments from Mr. Fookes might be extremely enlightening.

                    AFAIK (there I go "opining" again). He's subscribed to this list or used to
                    be anyways. I haven't seen much from him of late. Years ago he used to post
                    more often on this list if you, for example, search the older archives of
                    this list at Yahoo Groups.

                    (login to the www yahoo groups first, and then,)

                    Are you ready for nostalgia lane? Here goes:

                    summer of 2001

                    http://tech.groups.yahoo.com/group/ntb-clips/messages/7021?viscount=-30&l=1


                    summer of 2000

                    http://tech.groups.yahoo.com/group/ntb-clips/messages/4521?viscount=-30&l=1


                    Feb. 2000 -- 3 posts on this page of Messages 2571 - 2600 of 16051

                    http://tech.groups.yahoo.com/group/ntb-clips/messages/2600?viscount=-30&l=1

                    Summer 1999

                    http://tech.groups.yahoo.com/group/ntb-clips/messages/1200?viscount=-30&l=1

                    March 1999
                    http://tech.groups.yahoo.com/group/ntb-clips/messages/100?viscount=-30&l=1

                    March 1999 Messages 1 - 30 of 16051
                    http://tech.groups.yahoo.com/group/ntb-clips/messages/30?viscount=-30&l=1


                    http://tech.groups.yahoo.com/group/ntb-clips/

                    can go to there and scroll down to the message history for a profile of
                    traffic related. It appears it has tapered off a slight bit over the last
                    several years. Well, there's lots of archives to search now.

                    Also I just ran across this, an faq by Jody:

                    http://www.notetab.net/faq/ntb/index2.htm

                    and a frames version of the same:

                    http://www.notetab.net/faq/ntb/

                    --
                    Alan.
                  Your message has been successfully submitted and would be delivered to recipients shortly.