Still testing some things related to this and found a bit more.  When I use
a PLAYBACK file, instead of using NEXTROW, the edit-cursor and INTENSITY bar
remain current.  I previously avoided using PLAYBACK as, unfortunately, it
was too slow.  As such, the problem seems to be (generally) localized to
NEXTROW, PREVROW, and TIERed REGIONS ...

Later,
Steve in Memphis

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of J. Stephen Wills
> Sent: Monday, March 18, 2002 11:02 AM
> To: RBase List Server
> Subject: Forms.Region.Tiered.NEXTROW.INTENSITY => Navigation Problem
>
>
> Okay, I've created several forms w/tiered regions and tested this
> w/similar
> results.  I say similar because I just ain't gonna' take the time
> to isolate
> this behavior beyond what I've done so far, unless RBTI wants to
> hire me as
> a S/W Q/A Manager, and that's not a hint, because I already have a job and
> I'm tryin' to spend my time doing that job, using RBase as a tool
> to aid in
> the performance of that job.
>
> Anyway, the unexpected behavior observed is as follows.  While "EDIT USING
> FormName ...", in a tiered region, when an EEP issues a NEXTROW
> command that
> continues conditionally, the edit-cursor (NOT an SQL CURSOR, but
> that little
> vertical bar) and the INTENSITY-highlighted tier may go
> out-of-sync with one
> another.  This is occurs when a NEXTROW command moves off the last visible
> row of the tiered region.  The INSTENSITY-bar sticks at the (LastRow + 1),
> whereas the edit-cursor may behave unpredictably - the "unpredictability"
> facet here may simply be that I haven't identified more details about the
> problem and its potential causes, interdependencies, etc.
> Anyway, as EEP's
> are still being called, and their execution being conditionally controlled
> based on either COL||VAR values, which themselves were dependent, in part,
> on an expected sequence of execution, meaning, since this an EDIT
> USING ...,
> this record comes before that one, everything on my form goes to
> hell-in-a-handbasket.  (Umm, lest I be criticized on etiquette, I
> have heard
> my elders and forbears use such a term and I therefore consider it to be
> within the bounds of acceptable useage.)
>
> Okay, so I got basic.  I created a table, DUMMY, with 1 COL, "DUMMY_INT
> (INTEGER)".  I also created a simple form, with a region of 10 tiers,
> locating a Field for DUMMY_INT and defining a VAR, vDummy_INT = DUMMY_INT.
> I INSERTed a couple dozen records, so that I'd have more records then the
> tier could display.  Then I added this Field eNtry Procedure :
>
> --DUMMY_INT Test
> IF vDUMMY_INT < 15 THEN
>    NEXTROW
> ENDIF
>
> I've tested this and so should y'all.
>
> Also, and I don't mean this insincerely nor insultingly, but, having
> observed this behavior and now having taken the time to better
> define it, I
> don't want any patronizing or condescending responses from Razzak or RBTI.
> As I've said, I've been a user since the release date of System V, so any
> use of the terms such as "glorious" or "magical" will not only
> irritate me,
> but lead me to doubt those entities||attributes, Glory and Magic,
> especially
> as they are based on my perception of what the product does f/me now, not
> what I hope RBTI is going to do to improve the product.  Nor do I want to
> see any admonitions, albeit gentle, about remaining current w/my versions,
> as the problem either :
>
> - was present in the past
> or
> - is now present
>
> and, in either case, is wholly insufficient w/re: to S/W Q/A and expected
> performance.
>
> As I said, I don't mean to be ugly, but I paid my money and I ain't that
> happy right now.  So, in a cooperative spirit, I'll tell you
> exactly what I
> do want.  I want RBTI to test this, acknowledge that it is either
> a bug, or
> that the documentation is such that I, the user, could not have
> known about
> certain limitations in the use of EEP's, and that this will be
> addressed in
> v7, whether because it's fixed or because a change in the
> architecture of RB
> is such that it is irrelevant.
>
> Look, I been comin' back to RBase f/years now, but I keep gettin' the
> feeling of being a jilted lover.  So, all this rah-rah-rah-sis-boom-bah
> stuff is garbage in my ears.  I expect everyone at RBTI to be
> proud of their
> efforts, but I expect the bulk of that pride not come from vision,
> aspiration, motivation, but rather from the humble acceptance of
> praise from
> us, the developers and users, based on our positive perception that
> peformance is proof, end of discussion.  As my wife likes to tell
> me, and I
> think I once read it in Latin, "Actions speak louder than words."
>
> Lookin' fwd to what y'all have to say,
> Steve in Memphis
>
> ================================================
> TO SEE MESSAGE POSTING GUIDELINES:
> Send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: INTRO rbase-l
> ================================================
> TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: UNSUBSCRIBE rbase-l
> ================================================
> TO SEARCH ARCHIVES:
> http://www.mail-archive.com/rbase-l%40sonetmail.com/
>

================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/

Reply via email to