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