System variable holding the last-edited-record-Nbr in a Browse window ?

[SANTINI]

Hi. Happy New Year to y'all.
I need to find out what the VFP8 internal variable name is which keeps track of
the last-edited-record-number in a Browse window? Apparently, VFP has this, as
the Status Bar always indicates the current-record-nbr versus the total records in
the table, when the mouse or keyboard is moved to select the suitable record to
edit. I need this last-saved-record-number after I exit the Browse window for
recording... and I don't mean the bottom most record. It could be any record in
between. Or, is there another way to accomplish this? Thanks.

 

[Olaf Doschke]

Happy New Year to you, too.

There is no variable for that. Each work area has a current record position, not the browse window or grid.
If you address alias.id you get the id of that current record. And RECNO("alias") gives the record number.

Bye, Olaf.

 

[Mike Lewis]

To be exact, the number in the status bar is the number of the current record. That's not necessarily the same as the "last edited" or "last saved" record. As Olaf says, you can always find the number of the current record by using RECNO().

If you want to save the current record number so that you can return to it later, you just need to store the value returned by RECNO() to a variable of your choice. If you want to save the number of the last record that was edited, you can also save RECNO() to a variable, but you need to do that at the point at which you edit (or save) the record.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SANTINI]

Thanks Olaf and Mike for your help.
Yep, it works as you pointed out.
Have a good year ahead !!

 

[Olaf Doschke]

Thanks!

One more thing you can do, but only if your table is in a DBC: You can define triggers for INSERT/UPDATE/DELETE. VFP uses them mainly for establishing referential integrity rule checks, but you may log editings of records.

See

http://msdn.microsoft.com/en-us/library/yyx1k372(v=vs.80).aspx

Bye, Olaf.

 

[SANTINI]

Many thanks again Olaf. Will explore your tip.
Cheers!

 

[NasibKalsi]

Happy New Year !

To expand to above posts,
you could explore the Valid clause and then save the Edited record to your choice of variable name.

From the help file:
"Performs record-level validation in a Browse window. The VALID clause is executed only if a change is made to the record and you attempt to move the cursor to another record. The VALID clause is not executed if the only change is to a memo field."


nasib

 

[SANTINI]

Thank You Nasib. Appreciate your tip. Will certainly explore this.
Cheers!

 

[SANTINI]

Hello guys,
Sorry to bother you again. Still having a problem with "lost" Browse record pointers.
variablename = Recno() works, usually. My problem manifests itself when a command
button (inside a form) containing the procedure to Browse Table#1; retrieving
its last record number & a data, as the browse window closes. Then, this retrieved
data will be written into table#2. The record nbr will only prove we have the
correct data from the correct last-record accessed.

This varialbename = Recno() works 100% when it's inside a (.prg) program. However,
when the SAME codes invoked inside a Command Button's procedure, inside a Form, the
behavior is different. I don't know if it's a bug, or something wrong with my VFP7 & 8.
The odd thing is, the same codes used to open the browse window, to retrieve the last
record accessed and later writing the info into Table, results in Lost recno() and
Lost data when run normally. But, when Set STEP ON is invoked, and RESUMED, the problem
did not occur. In other words, it works perfectly! What's different when STEP is ON ?
I discovered this weird behavior when trying to debug it. I've tried re-installing
VFP8, and even VFP7, but the results are the same.

Obviously, one could not run a compiled program with STEP ON. So how to resolve this?
I've have created a short DEMO program showing this "bug". It's 7Kb only. It's called
"Statement.scx" and comes with its two sample tables in a zipx file. I don't know how to
post it, or if I could in this forum. So, perhaps I could email it to you, if you'd like.
A demo program is worth a thousand words. To see is to believe. You could test this
out as it's not compiled. Guaranteed no virus.

Thanks in advance for your help. God Blez.
Cheers !!

 

[Olaf Doschke]

See "click here to upload your file to ENGINEERING.com", follow instructions and you set your uploaded file as attachment.

RECNO() is no good choice in noting a record position. If you want last record GO BOTTOM.
My guess is, your scx is using a private datasession. That's making it open the dbf again. We'll see.

If you have two datasessions and the same table open twice, once in each datasession, and buffered, the newest record will only be seen in the datasession adding it, as it's not going into the DBF file unless you save the buffer. By default there is no buffering, though.

Bye, Olaf.

 

[SANTINI]

Hello again Olaf,
I will upload as per ur instruction. Here goes.
Thanks and hope you could see my problem.
Cheers.

 

[Olaf Doschke]

zipx doesn't unzip, create a normal zip.

Bye, Olaf.

 

[SANTINI]

Hi Olaf,
Here's the normal zip file.
Thanks.

 

[Olaf Doschke]

I don't fully understand your problem, but it might have to do with opening tables in the form activate event.

Activate happens more than once, each time you go to a form. And each time tables are used the record position will be top and no filter is set.
You also address tables via their hardcoded workarea number. Instead of SELE 1 and SELE 2 SELECT HISTORy and SELECT ACCTS, this also makes code much better readable.

In regard of the add/edit button you remember the recno of accts , then browse history, then reposition to the remembered acct record. You never moved in the accts table, since you only APPENDED a blank record and browsed history.dbf. In accts DBF you may be anywhere including EOF, where you can't replace. You first have to decide which account, then add a history record.

Also after SET FILTER always LOCATE, otherwise the filter is not yet active. GO BOTTOM then is wrong, it'll move to the last record, no matter if the filter condition is ok or not. I said GO BOTTOM is ok for finding the last record added from elsewhere, eg after any other client of a multi user app added records, you find the latest with GO BOTTOM. If you APPEND BLANK the record pointer will be that new record and you need to do nothing. But you're applying GO BOTTOM on the table you not append to.

But that is just the technical perspective on the working of REPLACE and FILTER and I don't really know what this form is trying to achieve. Recording some transaction and updating the last transaction date in the account used for the transaction?

How about Adding this before everything else:

Sele accts
SET FILTER TO category = tdisplay   
LOCATE
IF EOF("accts")
   Messagebox("no such account found")
   RETURN
ENDIF

Bye, Olaf.

 

[SANTINI]

Thanks Olaf for your feedback. I know it's hard to explain, hence the demo program.
Actually the ACCTS.dbf has a lot of records, but to keep it simple, I chose to
replace/update for this record only. What I try to achieve is that once History.dbf
(in this case "CHARITY") is selected, a browse window is invoked. Therein client is
free to navigate thru the various transaction(s) history and edit anywhere. As the
client moves up-and-down the various records, Browse automatically keeps track of the
accessed record number as evidenced in the Browse window Status Bar below. So, this
function is inherent to Browse. And I hope to get this latest-accessed record (not
necessarily the bottom record) whose history.date info I need to be posted into ACCTS.dbf.
This is to keep track of the DATE of last-edited/last-seen historical transaction.
So, in the future, recalculation or re-balancing of the historical transactions can
be performed starting from the latest-edited/seen transaction date, instead of from
the TOP or the Bottom record. This is to shorten re-balancing time.

Oh, I failed to point out. With STEP OFF, and Browse closes, Recno of History jumps to
the TOP record "MAMAMIA" which has " . . " for history.date. That's why the same
" . . " gets posted in ACCTS. <<undesirable>>

Somehow, my current codes work when SET STEP ON , and I achieved what I was hoping to.
i.e., Recno of History does not jump to "MAMAMIA" as above, and retained the last
record data --- I was able to obtain the desired history.date info. But it doesn't work
when run normally with SET STEP OFF. I want to know Why?
And, if there's a way to work around this "bug" or limitation? Maybe my copy of VFP8 is
faulty? Hope you could shed some light on this.

I use GO BOTT after Set Filter to implement the Filter condition. It may be redundant, I
know

Myriad thanks again for your time. God Blez.

 

[Olaf Doschke]

The first step to do is open data in form Load or init, not in Activate. See how it behaves then.

Bye, Olaf.

 

[SANTINI]

Hey Olaf, you hit the nail on the head. Yahoo!
Took your advice and opened the tables in INIT.
It's working. Thank you and more power! God Blez.
ciao.