I have a procedure that basically cleans up data when I enter it into a field. In Pan 6 I use a lot of Case Statements. Works fine.
I discovered that if I am on the first record and execute the procedure the procedure is executed and then the next record is activated when in Pan X. Going down one line in the data sheet.
The procedure below is culling out many steps to isolate the problem. This procedure normally is executed when a field is changed in many of the database fields.
If not on the first record then this event does not happen if there are multiple records.
If only one record the procedure works.
Because it only happens on the first record if there are multiple records selected it took me some time to isolate it. It did not happen all the time!
I have verified the problem on a virgin database too with PanX 10.2 rebooted.
Below is code:
;—Named ".StripsPasteData----culled to essence – one item Case
;this strips leading and trailing spaces and non-printable characters
It would be best to use Local variables when your procedure is using the variable and the variable’s value is not needed beyond the running of this single procedure.
When naming variables, use a prefix so that you can not accidentally use the same name as a field. In this case, if you needed a Local variable, you could name it LFieldName and you know that it is not conflicting with your field name and you also know that it is a Local variable.
Do recognize that FieldName is a statement and this could be the source of your conflict. Another reason to use the prefix of ‘L’ for local variables, ‘G’ for Global variables, etc.
In your procedure, you really do not need a variable at all. You could write this as
There is no need for a ‘Show’ as nothing had previously turned off screen updates. Abuse of the Show command (using when not really necessary) can create more confusion than any time that might be saved (and would not be noticeable anyway.)
I see nothing that would affect the workings of this regardless of the current record or the number of selected records.
As your primary need appears to be to remove accidental insertions of unprintable characters, you could instead use generic code that was something like…
«» = Strip(StripPrintable(«»))
When the chevrons are used without the field name, the current field is assumed.
I tried your code, I literally copied it from this forum page into a database. Works fine. Does not move the record down whether on the first record or any other record.
I second everything Robert said.
One other point is the case statement. I never use this any more, instead I use if elseif else endif. They work the same, however, it’s impossible to nest case statements, but if statements can be nested, as shown by the if x=y line in this example.
if a=b
if x=y
do something
endif
do another thing
elseif a=c
do yet another thing
else
this is like defaultcase
endif
However, none of this or what Robert has commented on is the cause of the behavior you are describing. And as I mentioned, your code doesn’t cause this behavior on my computer (nor would I expect it to).
The Show statement is deprecated and should no longer be used in new code. Show was to be used after a Hide statement in the old days and caused major problems if the active window was changed between the execution of the Hide statement and then later the execution of the Show statement. Your use without the Hide statement might be doing pretty much the same thing. Today we should be using the NoShow and EndNoShow statements instead.
If you want to update the display you can try a Showpage statement or even ShowOther «»,99 as a brute force tool to update the data sheet.
I can confirm that if I include the Hide Statement the procedure works. In the actual Pan 6 database the procedure was much larger and included a Hide Statement in the beginning. I just started to trim the procedure for troubleshooting.
Time to do a little housecleaning on my migrated databases.