Re: Refresh Problem

Dan,

Thanks again. I don't think SET REFRESH applies becuase I'm not using a
BROWSE window but I think you are on the right track.

I put and edit box on the main form and I had my TCP/IP control (which is
also on the main form) report to the edit box what state things are when an
UPDATE message is received and I am not seeing what I expected. I am seeing
locks when I should be seeing unlocks and the reverse.

This was my original thought about what the problem might be so I've taken
the following steps (which haven't worked)....

Lock / Unlock Workstation:
SELECT CONTENT
REPLACE RWUser with "" && for unlock
FLUSH
*** Send UPDATE messages to other workstations

Receiving Workstations
SELECT CONTENT
SET ORDER TO WindowID
GO TOP
LOCATE FOR WindowID = loWindow.cWindowID

The purpose of the GO TOP followed by the LOCATE was to insure that I had
the most recent copy of the data and the purpose of the FLUSH was to make
sure it got written before the receiving workstation tried to query it.

It now appears that I'm looking at old data even though the FLUSH is
executed before the messages are sent.

Is it possible that my TCP/IP messages travel faster than the system can
FLUSH the data to the drive?

I'm still puzzled since the 500ms MESSAGEBOX didn't seem to make a
difference.

I'm not sure what to try next.

Thanks,
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




.