• Subject: RE: Free OS/400
  • From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
  • Date: Wed, 11 Jul 2001 11:31:48 -0500
  • Importance: Normal



> -----Original Message-----
> From: James W. Kilgore
> Joe,
>
> Again I apologize for my hasty slapping together the code for
> maintaining a "simple" table. :)

No apologies necessary.  Instead, thanks for providing this.  This is a
realworld example, and it's the kind of thing I need to put the architecture
through its paces.  No matter how many test applications I design, they're
bound to be "tainted" with my own particular prejudices - only by using
other people's code can I get an idea of what I really need to do.  I ran
into this particular issue in spades with the Focus/2000 tool.  For example,
I defined a rule to handle the old MULT 100.0001 construct, and it worked
great.  And then I ran into a client who coded it this way:

   10000.01  MULT YMD       MDY

I had never anticipated that someone would put the constant in factor one; I
have ALWAYS put constants in factor two.  So real life examples are the only
way to really test.


> BTW, I forgot where the word "simple" came into play.  Was it that the
> table was simple, or programming for it was simple? ;-)

Well, to be honest, this is a little more involved than I had planned to
tackle, but that's okay.  Luckily I decided that I would allow up to 99
different record formats in a single display file, so I'm in good shape
there <grin>.  It's going to be fun running the DDS through my converter and
seeing how confused it gets.


> I'm no expert on Java, from which I understand is what your
> "revitalization" tool uses, but if I eliminated the INDARA keyword from
> my display files, which AFAIK would result in named fields being passed
> back and forth for the indicators, could you use that information to use
> getfocus?

Actually, right now I'm concentrating on the browser version, so it will be
using HTML.  I don't use applets.  I do support a Java thick client, but let
me get the HTML version working first.  I pass all the indicators, so that's
not the problem.  The problem is that once you move to a non-proportional
font, row and column lose their meaning - instead, the lowest granularity
for cursor position is field.  Besides, the idea is to allow the user to
move the fields around in the UI as they wish.  So, again, I'll need to
translate from field to row and cursor.  Also, picture this:

The user enters a field, then presses a button.  According to a strict
definition, the "cursor" is actually on the button.  So I'd have to keep
track of the "last field entered" and return the row and column
corresponding to the original position of the first character of that field.
This can be accomplished, but pretty much only through JavaScript, which I
have found is very incompatible from browser to browser.  So some of those
features may have to be revisited later.

Joe

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.