Hi
Several years ago Raining Data indicated the demise of Update. It cannot
happen soon enough. As for other peoples keyboards, that is why we stick to
ED and the prestores are magic, they take two minutes to learn as opposed to
the degree required for update.
Peter Mcmurray
"Dale" <benedictknowspam (AT) silk (DOT) net> wrote

On 2006-07-12, Luke Webber <luke (AT) webber (DOT) com.au> wrote:

The schmuck won't be unsuspecting, and 4GL sounds a bit grandiloquent,
but perhaps I'm out of touch. Yes, it's an automatically generated
data entry screen. That's what I want.

I want something to meet a need that I feel. Maybe no-one else feels
it. So maybe it will be used by no-one else. The objective is not to
develop something for someone else, unsuspecting or not.

Maybe there is a better way that I am ignorant of. Maybe (very
probably) there are capabilities in SQL (as it has so far been
implemented in PostgeSQL) that I'm totally ignorant of. It has just
occurred to me that doing these things was absolutely simple and
convenient with UP.

I'm just looking for a simple way of doing data input and update. In
particular, updating a text entry of about 10 lines (maybe an invoice
narration) to correct a spelling error, doing it with SQL, at least at
my level, means typing out the entire text again, and hopefully
getting it right this time, as part of an SQL update command. I want
to simply edit the existing text.

To confess, I'm a forensic document examiner. I charge by time. I
capture time and at the same time I type two kinds of text entries,
one a narration that will appear in the invoice and be perhaps two or
three lines long, just saying what I'm doing just now, and the other,
examination notes, what I'm seeing just now, and in a lot more detail
what I'm doing just now: some of which will eventually find its way
into the report. So between time A and time B for this client, this
rate, this charging system and so forth, I have in addition two text
fields.

After doing that I'd like to "ride the B-tree index" to visit and
check all the entries for this client. It is very easy to overcharge
if you had the timer on and the phone rang. I may need to enter time
in the "deduct" attribute for some of these entries. I want to be
able to visit them all in some order, check them, and perhaps, while
I'm doing that, update them in these several ways.

Doing a SELECT (an SQL one), printing all these items out, in the
first place makes a confusing mess with multiline entries, and then,
as a further process, you have to make the corrections with a series
of SQL statements.

Although PostgreSQL has indexes and indexing methods at least
equivalent to the B-trees of AP, in this different world things will
have to be done differently. Data independence, the desirability of
an update method that will work with views, the advisability of doing
everything via SQL and the virtual infeasibility of by-passing it if
you don't have a spare 50 years to study the code, these factors must
lead to an approach very different from that of AP and D3.

It will probably be a select list approach. You would select only the
indexed attribute, order by that attribute, store the list somewhere,
and then step through it, rather than stepping along the index.

On the subject of key mappings I do remember railing against the
absurdity of the UP choices when I first encountered UP. And I
remember thinking, why in the heck didn't they just... and then
realizing that virtually every key on the keyboard had been mapped.
When you need so many keys, i.e. you have so many functions, so much
functionality, you don't have a lot of freedom to conform with what
others have done. Emacs maps most keys, but most of what UP does you
can't do in Emacs. You need as many keys again.

In such a situation it is reasonable to start afresh, to independently
define a set of mappings. It seems to me that that is all that Dick
(if it was Dick) did. In the circumstances it seems silly to
criticise those choices on the grounds that other applications do
other things. It is a totally invalid criticism.

Well stated on all points Michael. Good for you.

To satisfy a small part of your requirements for fast update of
various tables without SQL, I'll just offer that there are a number of
webform generators that probably support PostgreSql, as well as the
new BLINQ technology. If you can't (easily) do what you want from the
command line then you may want to consider alternatives.

About your time keeping, I understand the concerns entirely as I
suspect many of our colleagues do. There are a number of timeclock
software packages that allow you to run multiple clocks, jump around
among records and record types, etc. - many of them are freeware.

Good luck finding/building solutions.

Tony

Michael Talbot-Wilson wrote:

Michael Talbot-Wilson wrote:
I had no idea that it was strictly for your own use. If so, it seems
fairly pointless asking about patents, because nobody is ever going to
know, right? <g>

There isn't all that much in SQL for actual data entry. SQL is something
that such a tool would need to use, but it can't do what you're asking for.

Sounds like the sort of thing that the OOo database tool could handle
very easily. OR Microsoft Access for that matter. All you need is a SQL query
at the back of it to specify the sort sequence, and if there is an index
on that column, you'll get virtually instant response.

Nope, just use one of the many tools available to build a GUI form. If
not OOo or Access, search on www.sourceforge.net - there are LOTS of 'em.

You say that as if it was a /bas/ thing. ;^)

The index will be automatically used if you use it as a sort key or as a
selection modifier.

Well, I happen to think that sequences like ctrl-x+ctrl-x are taking
things just a wee bit too far. Moreover, all screens have function keys,
and most 4GL designers have provided means of accessing them, but not
Dick. Hell, IBM's CUA standard was current when the UP was being written
- why didn't they use an extended form of that?

Weeellll, I just figured we'd come a long way from the old Wordstar
days, but the UP was dragging us back there. Putting the burden on the
user to learn 50 or so control-key combinations is a shitty answer to
the problem of navigation.

Luke

Luke Webber wrote:
Well, it's only ctrl+xx or ctrl-xy but no need to quibble about a
single keystroke.


Weeellll Luke, give it up dude. Anyone who has used vi/vim or similar
tools has to learn just as many key combinations with just as many
keystrokes. Using "$" to go to the end of a line requires shift+4 and
UP uses ctrl+f. To Go to a line in vi you use shift+g and in UP you
use ctrl+z.

In reality, as with other editors, the average user only needs about
10 keystrokes for day to day navigation, certainly not 50. I don't
care what navigation tool you use, if you have a user that can't
remember 10 keystrokes maybe it's time to re-evaluate employment
standards.

The fundamental difference between UP and other editors is that UP
assumes you're always in either insert or replace mode. Other editors
assume you're in navigation mode until you specifically invoke insert
or replace mode. Given the choice I would sort of prefer to use this
former explicit function mode but this is trivial. In order to get UP
to understand that you're issuing a command and not entering text, you
need to flag your keystroke, and that's done with the control key.
When one recognizes this fundamental difference in the way these
editors operate it becomes obvious why one needs an alternative
keyboard mapping.

Could UP be better with a customized mapping? Yes. But it's already
been asserted that you can map the keyboard any way you want through
terminal emulation. There are a lot of areas where UP is lacking
(backward searches, multiple undo, multiple stack pops...) but for a
basic tool it's usually not as bad as people make it out to be - or as
good.

T

Tony Gravagno wrote:
You can see how often I use it. <g>


Ah, but vi is modal, which means that most navigation keys are a single
keystroke, and the $/^ thing at least conforms to /some/ kind of
standard (regex patterns). And h/j/k/l are clustered together on the
keyboard and come close to conforming to their control-key equivalents.
And you can use the cursor keys as well, which is one thing the UP
doesn't even try to do.

Well, there's me. Not that I /can't/ remember them, but I certainly
can't be bothered to remember them. I remember enough of the keys I need
to use the TCL stacker, but not enough to drive UP. And I know people
who use TCL all the time, but never even bother with the stacker.
Because it's too weird. So why would I expose users to the same
alienating experience? It doesn't meet my standards, so I sure as hell
wouldn't put it in front of an actual user.

OTOH, UP could never fill an important role for me. I try never to use
tools that I can't take with me onto U2 or jBASE or whatever. I don't
like that lock-in.

YES. As I say, some editors are modal, and others go mad on control or
function keys. GUI editors can get away with defaulting to insert mode
because they have drop-down menus, toolbars and (usually well-known)
shortcut keys (like ctrl-c/ctrl-x/ctrl-v for cut/copy/paste). And vi
/does/ take a long time to learn. Obviously it is less than ideal as
well, though it is undoubtedly very powerful.

As long as you don't mind screwing up any other 4GL-ish tools, menu
systems, full-screen editors and what-not. <g>

As I say, I'm never likely to find out its good features, because I've
never been persuaded to make the effort to work past its obvious
shortcomings.

Cheers,
Luke

Luke:

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote in message ...

[snipped]

You're joking. I've been using vi for years and it's a, ahhhh, joke. :-)

If one just uses UP as a screen editor, with mapped keys, it's faaaaaarrrrrr
better than ED (or AE).

That may be true but I'll bet I can navigate through the tcl stack, and the
command line, at least 10 times faster than anyone, including me, can in one
of the U2 products.

Isn't that the truth! :-)

That's the rub. UP is everything in D3: TCL, dict entry, data entry,
program entry, etc...learn once, use anywhere. VI's not exactly that; just
another convoluted commands tool, amoungst many, to do one of many tasks.

It's amazing noone has come up with a simple tool that emulates most of what
UP does, in BASIC; then that would solve the huge cross-platform problem.
Assuming ED and AE aren't particularly useful tools, one might note that U2
hasn't any kind of useful interface. :-(

Bill