We recently upgraded to Arev 3.12 and now when we exit out of any of our screens it always asks: "You have unsaved changes are you sure you want to exit" yes or no. Is there anyway to turn that off? The problem we run into is that when we go into a screen with data that cannot be edited it still asks us that question when we escape out even though we didn't change anything or the data was protected. Any light on the subject would be greatly appreciated.

Are you using Collector Windows or Windows tied to the Database?

You can try the old

Orec=@record

as you exit the window

Claude

That was one reason we upgraded to 3.12 back in 1996; the users would hit escape, windows would exit without warning and the data entered would be lost.

Windows that, theoretically, don't change anything might be changing something you aren't aware of. Maybe purposefully, but maybe there is data being changed that you should know about or want to save. Or maybe you want to be sure it is not saved. You could check the original record with the window record about to be lost (or saved by the user!!) by comparing them field by field, and displaying any differences.

In our case we had a control field that contained information needed by a replication system, so that field was occasionally the culprit in these kind of cases. I think it is always good to know exactly why these things are happening, so you don't have nasty surprises lurking.

Oh, I agree with you on that, but we run into this problem with screens that have data or text in them that can't be edited. An example is our Order History. When the order is shipped and paid it goes into Order History where it can be accessed later down the road for reference purposes only. Sometimes there might be a description that is attached with that order that pops up in a window. That text cannot be edited or changed in any way except by the programmer, basically it is written in stone. But in the new version when you escape out of this window it tells you that you have unsaved changes. How is that possible if you cannot edit the text?

We are using windows that are tied to a database.

We are using windows that are tied to a database.

If I recall correctly from reviewing the window code, it checks wc_orec% (the original record in the state it was in before it was read into the window) against @record, the current record in the window. It is a simple matter of comparing the record byte by byte, so something in your @record must have been changed.

You might look for text manipulation occurring in the text box. But you can get to the bottom of the issue by doing your own compare in a pre-save program. Compare the records and display any differences. Or save them both to a file and print them out. If there is a change made to the record that you can live with, then add that change (that one only!) to the wc_orec% in the presave. Then that change will slip past the window check. But the implications of bypassing system functionality are often difficult to perceive. In this case, you may be saving text in a format that will break other display methods.

good luck!

Kenny

Betcha a beer that your window is changing @RECORD. You can verify this by hooking a piece of code to the Pre-Save process:

Subroutine Checkit

$insert include AREV_COMMON ; * or whatever you use

t1=@record

t2=wc_orec%

if len(t1)=len(t2) then

call msg('Same Length..Checking byte for byte')

end else

call msg('Different Lengths hmmmmmmmm...|Checking Further')

end

l1=len(t1)

l2=len(t2)

* scan both strings for the length of the longer …

if l1=l2 then

byte_count=l1

else

if l1 ] l2 then byte_count=l1 else byte_count=l2

end

for i=1 to byte_count

tst1=t1i,1

tst2=t2i,1

if tst1 ne tst2 then

  call msg('Different at Byte ':i:'|Current=:tst1:'|Orig  =:tst2)

end

next i

return

Dean,

You stated: "Sometimes there might be a description that is attached with that order that pops up in a window. That text cannot be edited or changed in any way except by the programmer, basically it is written in stone." Is it possible that the justification for the "description" prompt is different from its dictionary justification? If the text is originally without @TMs but is displayed with them, the data has changed. Hence, "unsaved changes." It's happened to me.

Sometimes multi-value text type fields will do this as well, esp T type conversions since the data displayed in the window is not the same as a data stored in the file.

[email protected]

Sprezzatura Group

View this thread on the forum...