Re: UP -- patent restricted?

Michael Talbot-Wilson wrote:
On 2006-07-12, Luke Webber <luke@xxxxxxxxxxxxx> wrote:

It appeared to me that Michael wants UP as a 4GL, not as an editor.
A tool for building applications, which will in turn be used by
some poor unsuspecting schmuck.

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

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.

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.

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.

Sounds like the sort of thing that the OOo database tool could handle
very easily. OR M$ 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.

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.

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.

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.

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

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.

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

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.

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 ***. Hell, IBM's CUA standard was current when the UP was being written - why didn't they use an extended form of that?

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 *** (if it was ***) 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.

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
.