Re: Refresh Problem

also, you can use a semaphore (flags) locking technique which will tell 'who'
is in control of the current record...

allan

"Cy Welch" wrote:

Jeff Grippe wrote:
It has something to do with the timing but I don't know exactly what.

If I wait 3 seconds between mouse clicks on the lock / unlock button, it
always updates correctly. The shorter the amount of time I take between
clicks, the more often it fails.

It all seems to come down to an instance of the program having a copy of the
data that is out of date.

I have no idea how to fix this.

Thanks again.

Jeff
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:%23JE2qq$vHHA.4132@xxxxxxxxxxxxxxxxxxxxxxx
So it actually has nothing whatsoever to do with actual locking? When you
say locking, we immediately think RLOCK().

What's your SET REFRESH setting?

I know from my stratigically placed MESSAGEBOX call that the receiving
workstation is looking at a current copy of the data. I placed my
MESSAGEBOX statement after all of the database lookups have been done
but before the loWindow.refresh.
No, you know that when MsgBox() *retrieves* data, you get current data. So
retrieve data another way:

luJunk=Content.RWUser

instead of the interruptive MsgBox().

Dan

Jeff Grippe wrote:
Dan,

I'm not sure what you are suggesting. I omitted details to keep the
message small but here is what happens (briefly)

Locking/Unlocking Workstation:
Set the database field RWUser to the user's ID for locking, set it to
null for unlocking.
Send a TCP/IP message to each user who has the same message open (The
TCP/IP message is an UPDATE message which basically means that
something has changed and that the receiver should refresh their
displayed copy of the message from the database)

Receiving Workstation:
When the workstation receives an UPDATE message it re-queries the
database to update up to four different items that are displayed.
They are: Locked or Unlocked Status (based on RWUser having a value or
being
empty) The Contents of the message itself.
The Subject of the message.
The list of other users that are also viewing the message.

I know from my stratigically placed MESSAGEBOX call that the receiving
workstation is looking at a current copy of the data. I placed my
MESSAGEBOX statement after all of the database lookups have been done
but before the loWindow.refresh.

With the MESSAGEBOX there (or SET STEP ON and then resuming in the
debugger), the window title always updates when the loWindow.refresh
is executed. Without something that stops the execution of the
program the window does not update every time.

Interestingly, when I used a MESSAGEBOX with a 500ms timeout, that
was the same as no MESSAGEBOX at all. The window did not update every
time. Only a messagebox with a pause for user interaction seems to
work.
I haven't tried Fred's suggestion but that is next on my list.

Thnaks,
Jeff
"Dan Freeman" <spam@xxxxxxxxxxxxx> wrote in message
news:OhG$OJ%23vHHA.3400@xxxxxxxxxxxxxxxxxxxxxxx
Workstations won't know about another workstation's locks until they
try to read the record. Instead of displaying the field contents, try
assigning it to a (unused) variable.

Dan

Jeff Grippe wrote:
Hello and thanks in advance for the help.

I am having one of those problems which goes away when you try to
observe it.

I have a shared messaging application in which the data can be
updated by any user. The user must lock the message before updating
and then unlock it when they are finished. When they press the lock
button, all other users viewing the message should have their title
bar changed to read "LOCKED BY USERX". When the user unlocks the
message the title bar should say "UNLOCKED".

The changing title bar works eratically and the problem seem to be
with the call to loWindow.refresh.

If I put in a debugging statement such as:

=MESSAGEBOX("Content.RWUser is " + ALLTRIM(content.rwuser))

right before loWindow.refresh,

It works every single time and as soon as I close the messagebox,
the refresh does what it is supposed to do.

If I take out the MESSAGEBOX statement it won't always refresh the
window.
Does anyone have any ideas about why refresh would behave eratically
at times?

Thanks,
Jeff



One thing I have found in these type of situations is that trying to
lock each record you need to be sure you are getting the right
information for tends to make it much more reliable. Trying to lock a
record both forces a flush and forces the record to be read from disk,
meaning FP will not assume what it has in memory is correct (which Fox
has a nasty habit of doing). For these situations I always just to an
RLOCK() followed by UNLOCK and the data seems to always be correct.

--
Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com

.

Quantcast