Jim,

Yes, with my form it is the column values that do not get updated and
redisplayed _without_ the need to go back through the rows. By the way, the
form is based on a temp table, not that I can see why that should be
relevant.

What is supposed to happen is that text data is entered in one column and
the EEP goes away and gets the code and puts it in the relevant code column
in the row. It was only when I added the code column to the form that I
found out why I was not getting the column updated properly during testing.

What's stranger is that I know that the EEP is doing most of its work as it
also checks to ensure that there is a matching code for the text and takes
me to a sub-form to add it if there isn't and it does this immediately on
leaving the row as expected. (I know that I could use a menu for this but I
have found it quicker for my data entry to have a menu on the data already
in the temp table than to go to a 20,000 row table for the menu as much of
the entry is repetitive in relation to the temp table.)

What's even stranger is that I have a pair of these text/code combination on
the form and one of them seems to update when going back up the form and the
other when I go down it again - and there is only one EEP!

Regards, Alastair.


----- Original Message -----
From: "Jim Blackburn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2002 1:29 AM
Subject: Re: Screen Restore


> Alastair:
> >I _assume_ to mean the original screen refreshed with the latest data.
>
> This is what seems logical, but it is not what is happening. At least,
changes in column values behind the columns on the screen are not being
redisplayed.
>
> This would be a handy capability, if it redisplayed every field on the
screen.  Then, you would not need to scroll through the rows to get the
values refreshed.
>
> As for setting it off, WHY? WHEN?
> In every eep? Does this mean it is not a setting? That it must be
explicitly stated in every eep? Perhaps if it is omitted from one eep, that
one would restore the screen. But, why bother when can not see a use.
>
> Jim Blackburn
> Kodiak
>
> Alastair Burr wrote:
> >
> > I'm puzzled by the SCREEN RESTORE command:
> >
> > According to the syntax the default is ON - so there _should_ be no need
to
> > specify ON under most conditions. Except that the syntax also says that
it
> > redisplays the ORIGINAL screen (my caps) which I _assume_ to mean the
> > original screen refreshed with the latest data.
> >
> > The syntax also says that, for Windows, if one EEP has it set to OFF
then
> > all must - I can understand this for EEPs called from within another EEP
but
> > not ALL.
> >
> > I also have a form where I have to "scroll" through the rows to get data
> > updated - usually having to go down and then back up the form at least
twice
> > before I am sure everything is correct. It does get updated but _only_
after
> > going into and out of each row _after_ having entered the data and left
the
> > row.
> >
> > Anybody able to shed any light?
> > Regards, Alastair.
> ================================================
> 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