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

16050Re: [Clip] Re: functional, but dysfunctional also onclipboardchange and ^!clip

Expand Messages
  • Alan
    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.
    • Show all 19 messages in this topic