Wish for small improvement to INPUT

[Criss French]

Thanks a lot Sebastian, I appreciate the effort.



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

[Sebastian Groeneveld]

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

[Michael Mattias]

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

MCM

[Criss French]

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

[Michael Mattias]

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")

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



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

[Criss French]

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

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

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?!?!

Why not try this?

FUNCTION newInput( default$, x$ )

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

END FUNCTION



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

[Sebastian Groeneveld]

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

[Michael Mattias]

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

[Criss French]

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

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

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

...
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?!?!