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

Another for my wish list

Expand Messages
  • Neil Smithline
    I know that pScripts, due to the oddities of the Palm OS, cannot interact with the user. For example, they can t pop up a form in the middle or ask the user to
    Message 1 of 16 , Nov 3, 2006
    • 0 Attachment
      I know that pScripts, due to the oddities of the Palm OS, cannot interact
      with the user. For example, they can't pop up a form in the middle or ask
      the user to press 'y' or 'n'. But is it the case that they can't interact be
      made to interact with users before they start running? For example:

      /* pMacro */
      {SimpleInputScreen::#FMaa /* use form */
      /&varSet@[$B, @@You entered: @@]
      /&varAdd[$B, $A] /* $A set by form
      /&mess[$B]
      }

      /* Form definition - syntax is just a sample */
      {#FMaa:: /* always happens "now" */
      /* only valid inside a form definition */
      /&prompt@[$A,"Enter text: "]
      }

      /* Initial screen */

      Enter text: _foo___________ (pretend that is an input box)


      /* Output screen */

      You entered: foo

      I think this should basically work. There would be limitations such as the
      form needing to be at the beginning and there is only a "now" version but
      who cares. It would still be very valuable. It would allow users to write
      custom tools like pMemoTool via pScripts. Furthermore, over time the types
      of inputs can grow so that I could specify different types such as date or
      time or positive integer or drop-down list and the input forms could then
      become more and more sophisticated.

      Now I'm far from a pScript internals expert so I don't really know if this
      can work but I think it should.

      Paul?

      - Neil


      [Non-text portions of this message have been removed]
    • John Markley
      Hi, Neil- I think it may be a while before Paul is able to respond, so let me ask some questions, in line, about this that might help you and him-- ... Do you
      Message 2 of 16 , Nov 3, 2006
      • 0 Attachment
        Hi, Neil-
        I think it may be a while before Paul is able to respond, so let me
        ask some questions, in line, about this that might help you and him--

        Quoting Neil Smithline <peditors@...>:

        > I know that pScripts, due to the oddities of the Palm OS, cannot interact
        > with the user. For example, they can't pop up a form in the middle or ask
        > the user to press 'y' or 'n'. But is it the case that they can't interact be
        > made to interact with users before they start running?

        Do you mean by this that pScripts will only run at the moment when
        specifically initiated by a triggering act of the user, and can't be
        made to self-start without the direct initiation of the user, during
        some designated sequence (which is true)?



        > For example:
        > /* pMacro */
        > {SimpleInputScreen::#FMaa /* use form */
        > /&varSet@[$B, @@You entered: @@]
        > /&varAdd[$B, $A] /* $A set by form
        > /&mess[$B]
        > }
        >
        > /* Form definition - syntax is just a sample */
        > {#FMaa:: /* always happens "now" */
        > /* only valid inside a form definition */
        > /&prompt@[$A,"Enter text: "]
        > }

        This looks like you're wanting to write a pMacro enabled pScript
        followed by a pMacro, but the syntax is wrong. Or are you giving an
        example of a new, as yet nonexistant syntax that you're wishing for
        ("syntax is just a sample")? Similarly, the pFunction "/&prompt@[]"
        does not currently exist. ??


        > /* Initial screen */
        >
        > Enter text: _foo___________ (pretend that is an input box)
        >
        >
        > /* Output screen */
        >
        > You entered: foo
        >
        > I think this should basically work. There would be limitations such as the
        > form needing to be at the beginning and there is only a "now" version but
        > who cares. It would still be very valuable. It would allow users to write
        > custom tools like pMemoTool via pScripts. Furthermore, over time the types
        > of inputs can grow so that I could specify different types such as date or
        > time or positive integer or drop-down list and the input forms could then
        > become more and more sophisticated.
        >
        > Now I'm far from a pScript internals expert so I don't really know if this
        > can work but I think it should.
        >
        > Paul?
        >
        > - Neil

        ~ John
      • Steve Kunkel
        I have also thought about this idea of introducing GUI elements into pScripts. I, also, am far from being an expert but it kindof seems that the
        Message 3 of 16 , Nov 3, 2006
        • 0 Attachment
          <all snipped>
          I have also thought about this idea of introducing GUI elements into
          pScripts. I, also, am far from being an expert but it kindof seems
          that the form _could_ be displayed in the middle of a pScript. THe
          pScriptEngines would have to be able to pause mid-execution and wait
          for the input (I think). Part of where pGUIs could get complicated
          though, would be in defining the geography of the elements. How big
          would the text field be? Where on the form would it be located?
          WHould it have a Label? Would the form have a title? And so on.
          Instead of "/&mess[@@"Hi"@@]," you'd have "/&myGUI[pForm, H=160,
          W=160, title="Form" pFormID=form#1", pLabel#1, H=60, W=40,
          title="Enter your name", pField1, H=40, W=80, title="", Boolean blah
          blah etc etc]" And that would be just to define the form's image ...
          You'd still have to handle the information added to the form upon
          execution !!!

          I dunno ... I have a hunch that for anything like this, the forms
          would have to be some kind of separate, all-new component of the
          pedit/pToolSet family.

          pMasterTool allows a user to assign applications to the "myAppl's"
          list. The information is then stored in a pMasterTool prefsDB and can
          be accessed by the pToolButtons. Maybe there could be a new "pForms"
          module that would allow the user to build a really simple customized
          form with different types of objects on it. That form would then be
          saved in the "pForms" prefsDB. Then when developing a pScript the
          user would add a "pForm pFunction" that would launch the pForm and
          monitor the appropriate GUI element (e.g. text input field) and close
          the form and return the value when appropriate. Like
          "/&form[form#1,getFieldString#1,$A]." The pForm pFunction would then
          open pForm#1 and monitor pField#1 for a text string, then get it and
          append it to pVariable A.

          Later versions of pForms could introduce pCheckbox, pPopup, pRepeatbutton, pEtc.

          LOL ... it makes perfect sense in the wacky world of steveLand !!! :o)

          I think something of this magnitude would constitute an entirely new
          product release, and hense wouldn't be seen for quite some time, if at
          all, given that PaulComputing is a one-man company... But hey, I'd
          surely pay a few extra $$ for pForm functionality ;-) :o}




          --
          ===SteveK====================
          myspace.com/stevekunkel, T5, WindowsXP, PocketMirror, Anagram,
          MacrosExpress, DateBk6, Bonsai, pToolSet, Hi-Launcher, IconsPlus,
          PalmRevolt, Pedit, Plucker, MobiPocket, RsrcEdit, Bird, VillageSim,
          MyKbd, and-on-and-on.
        • Neil Smithline
          John - I m talking about an entirely new feature - interactive user input in a pscript. The sample I gave, my initial comment said pMacro , it should have
          Message 4 of 16 , Nov 3, 2006
          • 0 Attachment
            John - I'm talking about an entirely new feature - interactive user input in
            a pscript. The sample I gave, my initial comment said "pMacro", it should
            have read "pScript" (my bad - I think of pScripts as macros and I guess I
            sometimes type that way too).

            Also, I don't use the "PM" characters (Pedit Macro), rather I use FM (ForM).


            What I'm hoping for is a simple startup page for macros where you can enter
            some data.

            Steve has replied with an even more ambitious proposal. He wants control
            over GUI elements (I'd settle for some dumb algorithm laying them out one
            per line or something), and he wants them to be mid-script (ie: happen in
            the middle of a pScript) instead of just the beginning. The GUI control
            seems just like extra coding, the mid-script part involves interacting with
            the pScriptEngines, the event queue, and the Palm OS in ways I don't really
            understand and am not sure is actually possible.

            All that being said, I refuse to let anyone trim my wish list! I am allowed
            to dream.

            - Neil

            On 11/3/06, John Markley <jmmjr@...> wrote:
            >
            > Hi, Neil-
            > I think it may be a while before Paul is able to respond, so let me
            > ask some questions, in line, about this that might help you and him--
            >
            > Quoting Neil Smithline <peditors@... <peditors%40smithline.net>
            > >:
            >
            > > I know that pScripts, due to the oddities of the Palm OS, cannot
            > interact
            > > with the user. For example, they can't pop up a form in the middle or
            > ask
            > > the user to press 'y' or 'n'. But is it the case that they can't
            > interact be
            > > made to interact with users before they start running?
            >
            > Do you mean by this that pScripts will only run at the moment when
            > specifically initiated by a triggering act of the user, and can't be
            > made to self-start without the direct initiation of the user, during
            > some designated sequence (which is true)?
            >
            > > For example:
            > > /* pMacro */
            > > {SimpleInputScreen::#FMaa /* use form */
            > > /&varSet@[$B, @@You entered: @@]
            > > /&varAdd[$B, $A] /* $A set by form
            > > /&mess[$B]
            > > }
            > >
            > > /* Form definition - syntax is just a sample */
            > > {#FMaa:: /* always happens "now" */
            > > /* only valid inside a form definition */
            > > /&prompt@[$A,"Enter text: "]
            > > }
            >
            > This looks like you're wanting to write a pMacro enabled pScript
            > followed by a pMacro, but the syntax is wrong. Or are you giving an
            > example of a new, as yet nonexistant syntax that you're wishing for
            > ("syntax is just a sample")? Similarly, the pFunction "/&prompt@[]"
            > does not currently exist. ??
            >
            > > /* Initial screen */
            > >
            > > Enter text: _foo___________ (pretend that is an input box)
            > >
            > >
            > > /* Output screen */
            > >
            > > You entered: foo
            > >
            > > I think this should basically work. There would be limitations such as
            > the
            > > form needing to be at the beginning and there is only a "now" version
            > but
            > > who cares. It would still be very valuable. It would allow users to
            > write
            > > custom tools like pMemoTool via pScripts. Furthermore, over time the
            > types
            > > of inputs can grow so that I could specify different types such as date
            > or
            > > time or positive integer or drop-down list and the input forms could
            > then
            > > become more and more sophisticated.
            > >
            > > Now I'm far from a pScript internals expert so I don't really know if
            > this
            > > can work but I think it should.
            > >
            > > Paul?
            > >
            > > - Neil
            >
            > ~ John
            >
            >


            [Non-text portions of this message have been removed]
          • John Markley
            Hi, Neil- ... Ah, so. Understand. All that being said, I refuse to let anyone trim my wish list! I am allowed ... Absolutely. Hang in. Clearly only
            Message 5 of 16 , Nov 4, 2006
            • 0 Attachment
              Hi, Neil-

              Quoting Neil Smithline <peditors@...>:

              > John - I'm talking about an entirely new feature - interactive user input in
              > a pscript. <<SNIP>> Also, I don't use the "PM" characters (Pedit
              > Macro), rather I use FM (ForM).
              >
              > What I'm hoping for is a simple startup page for macros where you can enter
              > some data.

              Ah, so. Understand.

              <<SNIP>> All that being said, I refuse to let anyone trim my wish list!
              I am allowed
              > to dream.
              > - Neil

              Absolutely. Hang in. Clearly only Paul can respond to this. It may
              be a while I think, but we'll see....

              ~ John
            • John Markley
              Hi, Neil- ... ... Could you describe from a user action/GUI result sequence what this would do? That is, 1) where do you start? In pedit, or in any
              Message 6 of 16 , Nov 4, 2006
              • 0 Attachment
                Hi, Neil-

                Quoting Neil Smithline <peditors@...>:

                > John - I'm talking about an entirely new feature - interactive user input in
                > a pscript.
                <<SNIP>>
                > What I'm hoping for is a simple startup page for macros where you can enter
                > some data.

                Could you describe from a user action/GUI result sequence what this
                would do? That is, 1) where do you start? In pedit, or in any text
                field, or in something like DateBk6, where.
                2) then what do you do--- call up the form you spoke of with a tap,
                press, something else, or what. What do you see on the screen as a
                result?
                3) then what, and then what, ..... etc., and what is the end result and
                what do you do with it? In you second sentence above is "macros"
                macros in general, or pScripts specifically?

                ~ John
              • Steve Kunkel
                That is, 1) where do you start? In pedit, or in any text ... It occurs to me that if you started from an active text field, you could (for some
                Message 7 of 16 , Nov 4, 2006
                • 0 Attachment
                  <sniparoonie>
                  That is, 1) where do you start? In pedit, or in any text
                  > field, or in something like DateBk6, where.<and snip>


                  It occurs to me that if you started from an active text field, you
                  could (for some purposes) use characters IN THAT text field to assign
                  properties to the variables of a pScript.

                  example:
                  I could write a pscript that automatiacally generates a sentence for
                  me, such as.

                  Your child, $A, has been assigend an academic tutor to help $B with $C
                  homework when $D needs it.

                  In this example,
                  $A = child's name
                  $B = pronoun "him" or "her"
                  $C = "his" or "her"
                  $D = "he" or "she"

                  Then, before activating the pscript, I enter (into the active text
                  field of DateBk6, pedit, etc) the following:
                  "Paulianna
                  F"

                  THe pscript then assesses the contents of the first line
                  ("Paulianna") and appends this to variable $A. It then assesses line
                  two and if "M" is present the 3 male pronouns are used for variables
                  B, C, and D. If "F" is present, the female pronouns are used.

                  THe example above would yield: "Your child, Pauliana, has been
                  assigned an academic tutor to help her with her homework when she
                  needs it."

                  SO in essence, the same text field that I plan to insert my automatic
                  sentence into serves as the GUI form to initiate the pscript.

                  Ah, yes ... steveLand my be foreign to everyone else; but it's a happy
                  place for steve :o)

                  --
                  ===SteveK====================
                  myspace.com/stevekunkel, T5, WindowsXP, PocketMirror, Anagram,
                  MacrosExpress, DateBk6, Bonsai, pToolSet, Hi-Launcher, IconsPlus,
                  PalmRevolt, Pedit, Plucker, MobiPocket, RsrcEdit, Bird, VillageSim,
                  MyKbd, and-on-and-on.
                • Neil Smithline
                  First, in general you should do a sed s/macro/script/g on all of my email. Sorry. I think of the scripts as macros and keep typing the wrong word. Sorry :-(
                  Message 8 of 16 , Nov 5, 2006
                  • 0 Attachment
                    First, in general you should do a "sed 's/macro/script/g" on all of my
                    email. Sorry. I think of the scripts as macros and keep typing the wrong
                    word. Sorry :-(

                    I can think of many answers to your questions. Here is what I suspect is the
                    simplest:

                    - You start out anywhere. Potentially from a screen that has input
                    fields on it but not neccessarily.
                    - You run a script (caught myself - typed macro initially - fixed it)
                    that is associated with a form. I think, to make things easiest, the form
                    should be the first thing, although Steve did suggest adding it mid-macro
                    would not be hard.
                    - The form would come up, it would be a "hack" screen. That is, it
                    would not exit the current program. It would show the fields displayed from
                    the form description. In my mind, pretty is secondary to functionality. I
                    would be happy if it just had one field per line and knew about perhaps 4
                    types, strings, dates, times, integers. That is, had appropriate choosers
                    for each.
                    - I'd fill out the form - hit OK and the script would run. If I hit
                    OK, the script exists.

                    As to how it is started, it is started anyway a script can be started. I
                    think I'd like to be able to start it DA-style such that the current
                    application does not have to exit. Having to use the p?Scripts would be less
                    convenient as they exit the current application but acceptable. Just plain
                    starting from a script runner would be fine.

                    Let me give you my prime motivating use case. I use Beyond Contacts. It has
                    a two page form for filling in a new appt. I only care about a few or 5
                    fields on the form, the label color (one of 11), the category(s), the
                    show-time-as free/busy, the date, the starting time, the ending time, the
                    alarm lead, and the subject.

                    All of these would fit nicely on one screen but they are scattered over two
                    screens in Beyond Contacts and many bring up annoying pop-ups (eg: category
                    chooser is a new screen. I'd like just to simplify. I'd be happy, on my
                    input screen, to use a single letter to short-hand my categories and the
                    script that ran would know how to translate them). I'd have to sit and watch
                    the script flip back and forth through the BC input screens (the file format
                    is proprietary and I don't have an interest in hacking it to add the record
                    directly) but I would be able to deal with that with glee (actually, the
                    current scripts I have are nice but I have about 20 of them for 20 different
                    variants of meetings (eg: busy v. not-busy, family members included v. not,
                    0, 15, 30 minute alarm setting etc...)

                    - Neil

                    On 11/4/06, John Markley <jmmjr@...> wrote:
                    >
                    > Hi, Neil-
                    >
                    > Quoting Neil Smithline <peditors@... <peditors%40smithline.net>
                    > >:
                    >
                    > > John - I'm talking about an entirely new feature - interactive user
                    > input in
                    > > a pscript.
                    > <<SNIP>>
                    > > What I'm hoping for is a simple startup page for macros where you can
                    > enter
                    > > some data.
                    >
                    > Could you describe from a user action/GUI result sequence what this
                    > would do? That is, 1) where do you start? In pedit, or in any text
                    > field, or in something like DateBk6, where.
                    > 2) then what do you do--- call up the form you spoke of with a tap,
                    > press, something else, or what. What do you see on the screen as a
                    > result?
                    > 3) then what, and then what, ..... etc., and what is the end result and
                    > what do you do with it? In you second sentence above is "macros"
                    > macros in general, or pScripts specifically?
                    >
                    > ~ John
                    >
                    >


                    [Non-text portions of this message have been removed]
                  • dmccunney
                    ... I see this thread, and my first thought is If what you ahve is pEdit/pToolset, everthing is a pScript... I m still thinking about this, but I feel that
                    Message 9 of 16 , Nov 5, 2006
                    • 0 Attachment
                      On 11/3/06, Neil Smithline <peditors@...> wrote:

                      > I know that pScripts, due to the oddities of the Palm OS, cannot interact
                      > with the user. For example, they can't pop up a form in the middle or ask
                      > the user to press 'y' or 'n'. But is it the case that they can't interact be
                      > made to interact with users before they start running? For example:

                      I see this thread, and my first thought is "If what you ahve is
                      pEdit/pToolset, everthing is a pScript..."

                      I'm still thinking about this, but I feel that adding GUI elements to
                      pscripting is probably the wrong way to go. My reference here is John
                      Ousterhout's Tool Command Language (Tcl, pronounced "tickle") which
                      originated under *nix and has been ported to Windows and the Mac. Tcl
                      was intended to be a "glue" language, allowing you to call other
                      functions. GUI elements were added seperately in an extension called
                      Tk. Tk does not require Tcl, and in fact is frequently used with
                      other script languages like Python in preference to Tcl.

                      One solution that might be worth investigating is Rexx. Rexx is a
                      script language that originated on IBM mainframs, and hase been ported
                      to a variety of other devices. IBM offers a free, open source
                      implementation called Open Object Rexx for PCs. Jaxo has a freeware
                      port to PalmOS available here: http://www.jaxo.com/rexx/

                      Another possibility might be Plua, a Palm port of the Lua scripting
                      language. There is a free 1.1 version available here:
                      http://www.freewarepalm.com/utilities/plua.shtml, and a 2.0 version
                      available through the Plua Yahoo group.

                      I believe GUI elements are available in Rexx and Plua. I don't know
                      offhand whether they can be mi8xed with pscript, but it sounds like it
                      might be possible.
                      ______
                      Dennis
                    • John Markley
                      Hi, Neil- ... Thank you. That is very clear. I was wondering whether you could get what you want with existing stuff,
                      Message 10 of 16 , Nov 5, 2006
                      • 0 Attachment
                        Hi, Neil-

                        Quoting Neil Smithline <peditors@...>:

                        >
                        > I can think of many answers to your questions. Here is what I suspect is the
                        > simplest:
                        >
                        > - You start out anywhere. Potentially from a screen that has input
                        > fields on it but not neccessarily.

                        <<big snip of all the important stuff>>

                        Thank you. That is very clear. I was wondering whether you could
                        get what you want with existing stuff, pedit/pTool plus other, somewhat
                        along the lines of Steve's most recent reply. But not so. You've
                        obviously thought it all through, and a new megafeature would be
                        needed. So I shall now be silent, pending comment from The Source.

                        ~ John
                      • Neil Smithline
                        Steve - You re one crazy guy. Yes - I like what you propose as well but it won t work for dates or times very well. Those are more awkward to enter into a text
                        Message 11 of 16 , Nov 5, 2006
                        • 0 Attachment
                          Steve - You're one crazy guy.

                          Yes - I like what you propose as well but it won't work for dates or times
                          very well. Those are more awkward to enter into a text field.

                          I think what you describe seems a bit different than what I've been
                          describing. What you describe seems to be implementable by adding two small
                          features:

                          1. The ability to automatically run a script when running pEditTool.
                          Probably need the ability to have multiple of these. Perhaps some fixed
                          number (Paul seems to like things in 16's) or perhaps the ability to specify
                          a specific script when running pEditTool. Or, perhaps the ability to specify
                          a lookup table when starting pEditTool of the form "if in screen X and
                          program Y, run pScript Z". The different solutions seem to have different
                          trade-offs (first is hard to specify, second limits to 16, third involves
                          table lookup and always runs same script from same field).
                          2. Some better string parsing in pScripts. I know some exists but, in
                          your example, you'd probably want the ability to break things up by space
                          delimiter, maybe handling double-quotes to combine multiple space-separated
                          words that should be in a single string (I guess double-@'s would be more
                          pScriptish). Then a method /&getWord[$A,n] where "n" specifies the n'th word
                          in the string.

                          From these two features, I think Steve's request could then be left as an
                          exercise to the peditor.

                          On the flip side, my request wants more formatted input mechanism than a
                          straight text field to handle dates and times. I want choosers for these.
                          Steve's suggestion, while sounding very cool, doesn't work for my use case.

                          - Neil

                          PS: Steve - by the way, the letters I usually get from school mention
                          detention and suspension. F's would be such a pleasant change :-)

                          On 11/4/06, Steve Kunkel <kunkel321@...> wrote:
                          >
                          > <sniparoonie>
                          > That is, 1) where do you start? In pedit, or in any text
                          > > field, or in something like DateBk6, where.<and snip>
                          >
                          > It occurs to me that if you started from an active text field, you
                          > could (for some purposes) use characters IN THAT text field to assign
                          > properties to the variables of a pScript.
                          >
                          > example:
                          > I could write a pscript that automatiacally generates a sentence for
                          > me, such as.
                          >
                          > Your child, $A, has been assigend an academic tutor to help $B with $C
                          > homework when $D needs it.
                          >
                          > In this example,
                          > $A = child's name
                          > $B = pronoun "him" or "her"
                          > $C = "his" or "her"
                          > $D = "he" or "she"
                          >
                          > Then, before activating the pscript, I enter (into the active text
                          > field of DateBk6, pedit, etc) the following:
                          > "Paulianna
                          > F"
                          >
                          > THe pscript then assesses the contents of the first line
                          > ("Paulianna") and appends this to variable $A. It then assesses line
                          > two and if "M" is present the 3 male pronouns are used for variables
                          > B, C, and D. If "F" is present, the female pronouns are used.
                          >
                          > THe example above would yield: "Your child, Pauliana, has been
                          > assigned an academic tutor to help her with her homework when she
                          > needs it."
                          >
                          > SO in essence, the same text field that I plan to insert my automatic
                          > sentence into serves as the GUI form to initiate the pscript.
                          >
                          > Ah, yes ... steveLand my be foreign to everyone else; but it's a happy
                          > place for steve :o)
                          >
                          > --
                          > ===SteveK====================
                          > myspace.com/stevekunkel, T5, WindowsXP, PocketMirror, Anagram,
                          > MacrosExpress, DateBk6, Bonsai, pToolSet, Hi-Launcher, IconsPlus,
                          > PalmRevolt, Pedit, Plucker, MobiPocket, RsrcEdit, Bird, VillageSim,
                          > MyKbd, and-on-and-on.
                          >
                          >


                          [Non-text portions of this message have been removed]
                        • Neil Smithline
                          I believe you forgot the quotes John. It should be The Source ;-) Yes - It is a mega-feature. - Neil ... [Non-text portions of this message have been
                          Message 12 of 16 , Nov 5, 2006
                          • 0 Attachment
                            I believe you forgot the quotes John. It should be "The Source" ;-)

                            Yes - It is a mega-feature.

                            - Neil

                            On 11/5/06, John Markley <jmmjr@...> wrote:
                            >
                            > Hi, Neil-
                            >
                            > Quoting Neil Smithline <peditors@... <peditors%40smithline.net>
                            > >:
                            >
                            > >
                            > > I can think of many answers to your questions. Here is what I suspect is
                            > the
                            > > simplest:
                            > >
                            > > - You start out anywhere. Potentially from a screen that has input
                            > > fields on it but not neccessarily.
                            >
                            > <<big snip of all the important stuff>>
                            >
                            > Thank you. That is very clear. I was wondering whether you could
                            > get what you want with existing stuff, pedit/pTool plus other, somewhat
                            > along the lines of Steve's most recent reply. But not so. You've
                            > obviously thought it all through, and a new megafeature would be
                            > needed. So I shall now be silent, pending comment from The Source.
                            >
                            > ~ John
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • John Markley
                            Hi, Neil- ... Upon further reflection, if Paul does decide to implement this, it would probably be better as a new pToolSet module ( pFormTool ), rather than
                            Message 13 of 16 , Nov 6, 2006
                            • 0 Attachment
                              Hi, Neil-

                              Quoting Neil Smithline <peditors@...>:

                              > I believe you forgot the quotes John. It should be "The Source" ;-)
                              >
                              > Yes - It is a mega-feature.
                              > - Neil

                              Upon further reflection, if Paul does decide to implement this, it
                              would probably be better as a new pToolSet module ("pFormTool"), rather
                              than as an extension of pScripting. ??
                              ~ John
                            • Neil Smithline
                              I thought about that and it has pros and cons. The pro is that the toolset already has the DA-type interaction that one wants. The con is that the tools don t
                              Message 14 of 16 , Nov 6, 2006
                              • 0 Attachment
                                I thought about that and it has pros and cons. The pro is that the toolset
                                already has the DA-type interaction that one wants. The con is that the
                                tools don't interface well with pScripts. How would I get a value out of a
                                tool? Would /&specAct return a value or set $$ or something? That seems
                                relatively non-obvious to me. That being said, it does seem more "tool"ish
                                than "script"ish. I think, if it was implemented as a tool and the tool had,
                                once the user hit OK, the ability to run a specified script and that script
                                could get the values out of the form, then it would be great.

                                - Neil

                                On 11/6/06, John Markley <jmmjr@...> wrote:
                                >
                                > Hi, Neil-
                                >
                                > Quoting Neil Smithline <peditors@... <peditors%40smithline.net>
                                > >:
                                >
                                > > I believe you forgot the quotes John. It should be "The Source" ;-)
                                > >
                                > > Yes - It is a mega-feature.
                                > > - Neil
                                >
                                > Upon further reflection, if Paul does decide to implement this, it
                                > would probably be better as a new pToolSet module ("pFormTool"), rather
                                > than as an extension of pScripting. ??
                                > ~ John
                                >
                                >


                                [Non-text portions of this message have been removed]
                              • John Markley
                                ... Oh, pTool is definitely pScript friendly, in fact you don t need pedit at all for pScripting, can do with pTool alone. Relevant pToolSet modules are
                                Message 15 of 16 , Nov 6, 2006
                                • 0 Attachment
                                  Quoting Neil Smithline <peditors@...>:

                                  > I thought about that and it has pros and cons. The pro is that the toolset
                                  > already has the DA-type interaction that one wants. The con is that the
                                  > tools don't interface well with pScripts. How would I get a value out of a
                                  > tool? Would /&specAct return a value or set $$ or something? That seems
                                  > relatively non-obvious to me. That being said, it does seem more "tool"ish
                                  > than "script"ish. I think, if it was implemented as a tool and the tool had,
                                  > once the user hit OK, the ability to run a specified script and that script
                                  > could get the values out of the form, then it would be great.

                                  Oh, pTool is definitely pScript friendly, in fact you don't need
                                  pedit at all for pScripting, can do with pTool alone. Relevant
                                  pToolSet modules are pScriptTool, pScriptButtons, and pScriptPad, as
                                  well as the functions (buttons, strokes, taps, and SpecActIds)
                                  available through pToolSet preferences. If pTool is on you can launch
                                  pScripts a bunch of ways, and certainly (I think), a pScript launch
                                  could be built into the kind of module (pFormTool?) you've described.

                                  ~ John
                                • Neil Smithline
                                  Cool - when can I try a beta? ... - Neil ... [Non-text portions of this message have been removed]
                                  Message 16 of 16 , Nov 6, 2006
                                  • 0 Attachment
                                    Cool - when can I try a beta?

                                    :-)

                                    - Neil

                                    On 11/6/06, John Markley <jmmjr@...> wrote:
                                    >
                                    > Quoting Neil Smithline <peditors@...<peditors%40smithline.net>
                                    > >:
                                    >
                                    > > I thought about that and it has pros and cons. The pro is that the
                                    > toolset
                                    > > already has the DA-type interaction that one wants. The con is that the
                                    > > tools don't interface well with pScripts. How would I get a value out of
                                    > a
                                    > > tool? Would /&specAct return a value or set $$ or something? That seems
                                    > > relatively non-obvious to me. That being said, it does seem more
                                    > "tool"ish
                                    > > than "script"ish. I think, if it was implemented as a tool and the tool
                                    > had,
                                    > > once the user hit OK, the ability to run a specified script and that
                                    > script
                                    > > could get the values out of the form, then it would be great.
                                    >
                                    > Oh, pTool is definitely pScript friendly, in fact you don't need
                                    > pedit at all for pScripting, can do with pTool alone. Relevant
                                    > pToolSet modules are pScriptTool, pScriptButtons, and pScriptPad, as
                                    > well as the functions (buttons, strokes, taps, and SpecActIds)
                                    > available through pToolSet preferences. If pTool is on you can launch
                                    > pScripts a bunch of ways, and certainly (I think), a pScript launch
                                    > could be built into the kind of module (pFormTool?) you've described.
                                    >
                                    > ~ John
                                    >
                                    >


                                    [Non-text portions of this message have been removed]
                                  Your message has been successfully submitted and would be delivered to recipients shortly.