Announcement

Collapse
No announcement yet.

Wish for small improvement to INPUT

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wish for small improvement to INPUT

    For so many years I have wished that you could do this...

    Code:
    ...
    filnam$=""
    a$="c:\data\default.dat"
    INPUT @ "Please enter datafile name > ", a$, filnam$
    ...
    The '@' symbol stands for my wish. Pick your favourite and least confusing thingy to put there. You would see on the screen...

    Code:
    Please enter datafile name > c:\data\default.dat_
    Where the '_' is the cursor. If you entered nothing and just hit return, then filnam$ would = "c:\data\default.dat". Importantly, you could use the already existing input editing functionality to modify the old value. Think of this as pre-stuffing the INPUT line with keystrokes supplied by a string (like a$). This should be dead simple. It would obviously be up to the programmer to provide an appropriate 'pre-stuff' string for the data type(s) of the variable(s) they want the user to input.

    The purpose of this proposal is to improve and simplify the 30 minute, no frills, 'can you hack me out something to do this...' type of program. It spoils the eloquence, compactness, simplicity and size of a 'quick and dirty' to always have to sub out for something so absolutely fundamental as an editable, defaulted value user input. The jerk who originally made the INPUT statement did something as bad as car with no filler on the gas tank, as far as I'm concerned. Should we really have had Doskey? Command.com has always been lacking. Many 'other' shells have been born to address just that alone, by building it in. I think that INPUT pre-stuffing merits being built in, and should always have been. It takes too big a chunk of code to fully re-invent all the functionality of INPUT, just to get this one most needed little improvement.

    How about this...

    Code:
    ...
    rem unam$ & filnam$ are read here from a prior settings file
    ...
    rem default inputs with own pre-defined target strings
    INPUT @ "Edit the datafile name > ", filnam$, filnam$
    INPUT @ "Is your name correct?  > ", unam$, unam$
    ...
    I think that the value added here would greatly improve the 'quick and dirties' in my life, from both a coding concience and a user=happy (often me) perspective.

    So in the words of Roger Rabbit,

    P bbbbbbbbbllleeeeez?

    ... well ok, now I'm done whining I can wait for the next update



    ------------------
    What can go wrong will go wrong.
    Anything can go wrong.
    What hasn't?!?!
    What can go wrong will go wrong.
    Anything can go wrong.
    What hasn't?!?!

  • #2
    It takes too big a chunk of code to fully re-invent all the functionality of INPUT..
    Not really. What you can do is replace INPUT with a "string editor" which allows for default, includes the X & Y positions in the call parameters, the maximum length of the field and/or the colors to be used.

    There's a bunch of string editors for PB/DOS floating around. You can probably find a couple in the ABC packets at http://www.basicguru.com .

    I wrote one as a unit file for PB/DOS and put it in the public domain, oh, gotta be seven-eight years ago now. Maybe I'll get that posted here this week if you think you want to go that way.

    MCM

    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      My previous PB units page got removed by Tripod (I still don't know why), and now I'm planning to rebuild it...
      So the link I'm posting here does not have very exciting contents yet, except some links...
      http://dracuul.tripod.com/pbdos/
      You might be interested in the unit "LineEdit":
      Features:
      - Maximum string length and maximum edit-field length may differ
      - Default text (start value) can be specified
      - Function returns last key press
      - Optional callback routine address can be specified (read the text file to see how it works)
      - Edit field is padded using FLEXCHR$
      - Insert/Overwrite mode supported
      - Ctrl-left and Ctrl-right for quick cursor movement
      - Ctrl-home and Ctrl-end for quick erase
      - Variable initial cursor placement
      - Release timeslices when idle in Windows DOS box

      If you have any questions about any unit ask me...

      ------------------
      Sebastian Groeneveld
      mailto:[email protected][email protected]</A>

      [This message has been edited by Sebastian Groeneveld (edited December 05, 2001).]
      Sebastian Groeneveld
      mailto:[email protected][email protected]</A>

      Comment


      • #4
        Why not try this?

        FUNCTION newInput( default$, x$ )

        input x$
        if ltrim$(rtrim$(x$))="" then x$=default$

        END FUNCTION



        ------------------

        Comment


        • #5
          In reply to Michael Mattias and Sebastian Groeneveld, thank you both for the feedback and code offerings. I am aware of the availablility of this category of functions, and look forward to checking out your stuff. I am just starting to really dig in to PowerBASIC, and get all my tools together. Sorry, I really ran-on below, if you want to read it, please allow it to serve as (sort of) a personal introduction. I expect to be around here a little from now on.

          In reply to David Venable, scroll way down. Sorry, I really got going...

          I just recently crawled out of the dark ages of QB4.0 to the dawn of PowerBASIC. I have built and maintained a small flock of data collection and processing programs for about 10 years now. It all started off when I (the computer guy on the crew) inherited a few custom programs (including source) from a fellow who had thrown them together rather quickly as a favour for my survey boss. It was all QB4.0 and I had the QB manuals in books. I cludged along in QB for years with "gotta learn C, gotta re-write" as my mantra. Then my life fell apart last January and I said, gotta cope, gotta cope. So I hit the net with (god bless> Google and looked up 'quick basic programming', hoping to, for once and all, find some answers to hair pulling i/o problems I was having (try serial i/o errors that wipe big append-only data files clean empty- not funny - 2 hours for survey crew in field - cartons of eggs-in-face). I had just assumed that anything other than M$ VB was long gone non-existant. DUMB. I had never looked, really, not once. I like Basic ; I have 10 years of code (some quite proud) to keep using. Within half an hour I found PowerBASIC, and never really looked back. I just never knew.

          So... I never have wanted to add anything I could possibly avoid to my QB programs, lest chaos ensue. Especially no multiple modules, linking .obj's, libraries, or ASM. The most I did was includes for some headers and data types, which worked (near miracle!). It was 1 big flat file, 64K max, all the way. 'Smaller is Better' the operative. It always drove me mad that INPUT was so close to meeting all my meager needs, but yet so far. Probably well less than 1/4k more ASM to add simple pre-stuffing to the existing basic input command. If I was a hacker with ASM in my repetoire I'd 'av put'er in meeself, problem solved (ok, maybe not really easy...).

          Now that I'm in a land where things work, I will end up using an input editor of some sort. Probably will start using Vision when I get a spare week to learn/play; it will be nice to build nicer looking and mouse aware wrappers for quite a few of my utilities.

          Still, there is a place for the clean little no frills, sub 100 liners. Progs where I can send one file to my survey buddy (who does program his calculator) that he can read and understand, and even modify if the need arises. Call it edu-ware. Sometimes that's exactly the job that needs to be done. It's nice if the language covers the basics well. PowerBASIC is extremely impressive thus far. My first read of the reference guide has been a big string of exstatic, lusty Yeesss's for me; so many it should have been like so...'s have turned out exactly like so. Very many Ooohhhs at improvements where I recognise the problem after seeing it cleverly answered. So I have made my years old wish known, I still think it has a little merrit.

          ........................

          In reply to David Venable, your suggestion doesn't allow editing of the previous value. If you have a name (I always have data file names) that is probably right, or mostly right, you don't want to re-type the whole works to change 1 or 2 characters. I usually have something like "e:\lake\south\bay3.yxz" as a filename (hydrographic surveying), and I want to change it to e:\lake\south\bay4.yxz". My programs often check for a '.' in the filename, and if not found add a '.yxz' (the default extension in this case), an economical 1 extra line. So if I even need to change the filename, I just want to go DEL, DEL, DEL, DEL, DEL, 4, ENTER, and be done. Handy when a boat is bobbing up and down on the waves and the keyboard on the survey computer is small.

          Another example use is where you have a path to probably be applied to several filenames. If you ask for the 'working directory' first, then the filenames...
          Code:
          INPUT "Directory for files > ", workdir$
          INPUT "Data file 1 name    > ", datafil1$
          INPUT "Data file 2 name    > ", datafil2$
          INPUT "Data file 3 name    > ", datafil3$
          datafil1$=workdir$+datafil1$
          datafil2$=workdir$+datafil2$
          datafil3$=workdir$+datafil3$
          ...then you can't change the path for one execptional file. My suggested syntax could use...
          Code:
          INPUT   "Directory for files > ", workdir$
          INPUT @ "Data file 1 name    > ", workdir$, datafil1$
          INPUT @ "Data file 2 name    > ", workdir$, datafil2$
          INPUT @ "Data file 3 name    > ", workdir$, datafil3$
          ...and you could use the in-built simple line editing to change the path for any of the files, if you needed to.



          ------------------
          What can go wrong will go wrong.
          Anything can go wrong.
          What hasn't?!?!
          What can go wrong will go wrong.
          Anything can go wrong.
          What hasn't?!?!

          Comment


          • #6
            Ok, I'm sorry. I didn't read all of your post
            Well, I wrote a string editor a while back that
            works really well for me. It's a basic one that
            I update depending on my needs for each program.
            Feel free to use it, change it, whatever else, but
            please let me know if you see any bugs or anything.

            (the comments aren't all that great, I just kinda
            threw them in there just now)


            ' zinput$ is similar to input, however it allows for text editing, insert
            ' key, home, end, delete, and so on and so forth. default$ is the default
            ' response, and the function returns its response. It doesn't read from or
            ' write to standard input/output. Also, it doesn't write a newline when it
            ' has finished.
            '
            ' currently, it will report an error if the input is past
            ' the current screen size
            '
            ' Example usage:
            ' print "What is your name? ";
            ' n$=zinput$("Dave")
            '

            FUNCTION zinput$( default$ ) LOCAL PUBLIC

            locate ,,1
            ctext$=default$
            startX = csrlin
            startY = pos
            locate startX, startY
            CursorX = startX
            CursorY = startY

            do

            maxY=len(ctext$)+startY
            locate startX, startY
            print space$(clen);
            locate startX, StartY

            ' If you want to use this function to get passwords
            ' you could use a line like this:
            ' print string$(len(ctext$), "*");
            ' instead of this line:
            print ctext$;

            clen=len(ctext$)

            locate cursorX, cursorY

            do
            nch$=inkey$
            loop while nch$=""

            if nch$=chr$(13) then ' enter key
            function=ctext$
            exit function
            end if

            if nch$=chr$(00)+chr$(75) then ' left arrow
            if cursorY=startY then iterate loop
            decr cursorY:iterate loop
            end if

            if nch$=chr$(00)+chr$(77) then ' right arrow
            if cursorY=maxY then iterate loop
            incr cursorY:iterate loop
            end if

            if nch$=chr$(8) then 'backspace
            if cursorY=starty then iterate loop
            lok=cursorY-starty+1
            l$=left$(ctext$, lok-2)
            r$=right$(ctext$, len(ctext$)-lok+1)
            ctext$=l$+r$
            decr cursorY
            iterate loop
            end if


            if nch$=chr$(0)+chr$(83) then 'delete
            if cursorY=maxY then iterate loop
            lok=cursorY-startY+1
            l$=left$(ctext$, lok-1)
            r$=right$(ctext$, len(ctext$)-lok)
            ctext$=l$+r$
            iterate loop
            end if

            if nch$=chr$(0)+chr$(82) then ' insert key
            if insertison=1 then
            insertison=0
            locate ,,,6,7
            elseif insertison=0 then
            insertison=1
            locate ,,,3,7
            end if
            iterate loop
            end if

            if nch$=chr$(0)+chr$(71) then 'Home key
            CursorY=startY
            iterate loop
            end if

            if nch$=chr$(0)+chr$(79) then 'End key
            CursorY=maxY
            iterate loop
            end if


            ' this handles any unsupported keys
            if len(nch$)=2 then iterate loop


            ' If you want zinput to return the default if the user
            ' presses Esc, then comment the next line and uncomment
            ' the next 4 lines.

            if nch$=chr$(27) then iterate loop

            ' if nch$=chr$(27) then
            ' function=default$
            ' exit function
            ' end if


            ' *** add a character ***
            lok=cursorY-startY
            ' get the left section of the string
            ' in relation to the cursor
            l$=left$(ctext$, lok)

            ' now, if insert is off, then we don't get
            ' the current character that the cursor is on.
            ' if the cursor is at the farthest space to the
            ' right of ctext$, then we don't get anything.
            if insertison=0 or cursory=maxy then
            r$=right$(ctext$, len(ctext$)-lok)
            else
            r$=right$(ctext$, len(ctext$)-lok-1)
            end if


            ' I did it this way because it was a lot easier.
            ' If it allows tabs, then it has problems figuring
            ' out where the cursor should be.
            if nch$=chr$(09) then nch$=space$(6)

            ctext$=l$+nch$+r$

            ' this is necessary because tabs get replaced with
            ' spaces.
            incr cursorY, len(nch$)

            loop

            END FUNCTION



            ------------------

            Comment


            • #7
              I downloaded Mr. Groeneveld's offerering, and I notice one problem with it right off:It is a PBU file minus source code.

              This is a problem because PB/DOS PBU files are PB-version specific, and I cannot find in the documentation under which PB/DOS version the unit was compiled.

              Something to keep in mind when offering "PBU" files...

              MCM
              (Also doc does not say how you can operate if "I don't want to use the callbacks")


              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                I downloaded it too, and it is reasonably thourough. I didn't twig to the 'which PB version' issue, but thanks for the forwarning. I presume that PB would complain if it didn't like the unit / wrong version. As for the callback functions, I surely hope that a test for null is made on each pointer before each pointer is jumped to. If so, providing a 0??? in place of the pointer would disable the respective callback. Comments would be very welcome Sebastian.

                I also note that although the function is thourough, it is a 'big call' (many args) compared to a normal input statement (few args). I will probably write a simple 'pre-stuffable' input replacement that calls with just the prompt-line$, the stuff$, and the result$. Oh yeah, and a numeric one that does the same but uses a result##. That is a definite advantage to using a native INPUT for the job, ie. that it uses the advantage of being compiled to be able to automatically convert the user input to whatever data type you specify in the INPUT statement, whereas with a composit function you need to remember to convert the data types yourself or have a different func per type. Not a big deal, but still a setback in edu-ware, or when cranking out code when hung-over, etc..

                I did crank out a pretty fancy input editor myself once, part of a data collection program. It supports editing numbers around a fixed decimal place (or not), and has various text editing fancy's too. It's also designed to handle a whole horizontal line of feilds at a time, moving through the feilds in sequence. Kind of like working on one line of a spreadsheet at a time. When I revisit that code ('tis still QB4) I'll try to make it available.


                ------------------
                What can go wrong will go wrong.
                Anything can go wrong.
                What hasn't?!?!

                [This message has been edited by Criss French (edited December 08, 2001).]
                What can go wrong will go wrong.
                Anything can go wrong.
                What hasn't?!?!

                Comment


                • #9
                  FWIW, I posted my string editor source code in the source code forum earlier today.

                  MCM
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Indeed I should have mentioned the required version of PB in my previous post.
                    As I said, that webpage was only a quick draft to enable the download of the units.

                    The units are compiled with PB/DOS 3.5... I will soon try to compile them with PB 3.2
                    as well and put them on the site.

                    About the question about the callback function: when you pass value 0??? for any of the function
                    pointers, the callback is ignored... it seems that I have forgotten to mention this in the docs
                    as well, how careless...

                    Furthermore I will add a simplified function, that will require less arguments (and
                    support less features), but give me some time for this...

                    I also added a single PBH help file for all the units. Please continue to report
                    problems and questions

                    ------------------
                    Sebastian Groeneveld
                    mailto:[email protected][email protected]</A>

                    [This message has been edited by Sebastian Groeneveld (edited December 10, 2001).]
                    Sebastian Groeneveld
                    mailto:[email protected][email protected]</A>

                    Comment


                    • #11
                      Thanks a lot Sebastian, I appreciate the effort.



                      ------------------
                      What can go wrong will go wrong.
                      Anything can go wrong.
                      What hasn't?!?!
                      What can go wrong will go wrong.
                      Anything can go wrong.
                      What hasn't?!?!

                      Comment

                      Working...
                      X