Now it functions to make “58” into “581” instead of "59. I read here elsewhere a note that the clipboard now only contains text, not numbers. So I’ve been thrashing around, just having jumped (or was I pushed by Mojave?) from Pan6 to PanX, to find the solution.
I used to be semi-smart about this stuff, but after nearly 3 decades of using Panorama, my brain seems to have fossilized – not Panorama’s fault, of course!
I looked at the “sequence” function, but I only need to change one record, not fill in all below. Fiddled with “let” and wrangling the “clipboard(” but no joy yet.
Your best bet is to avoid using the clipboard for this sort of thing. If you use a variable to hold the intermediate value, its datatype will be preserved.
UpRecord
Let theNumber = «»
DownRecord
Cell theNumber+1
DownRecord
The empty chevrons stand for the current field. You type « by pressing option - \ and you type » by pressing shift - option - \.
Fantastico! Exactly what I needed, Dave. I like to think I was on the right track with “let”, but the «» bit would almost certainly have eluded me for days, if not weeks. Thanks for your help. Now I have to edit that action in about 20-30 Pan6 dbs…
I think the easiest way to get that done with every new record that you add to your database is to set the “Default Value” property of your number field to “+1”.
I do that when I’m adding new records, and it works well (and still works in PanX). But this DB is a list of books read and to be read, cataloging with commentary, etc. There are about 4000 titles listed, but over 500 of them are TBRs (to be read). The active part is where the just read title bumps up against the TBRs, and it is only that record which needs the increment, which happens in more than one field. Now, speaking of the border between done and TBR, I need to get my procedure that took me to that borderline to work – I must have set that up 20 years ago or more, but PanX doesn’t keep me at the latest done book when I resort by sequence. This happens to many of my kludges when progress happens…
I think Dave’s solution is the best, and I have said many times that using the clipboard for this sort of thing should be avoided.
That said, this could be done using the clipboard, just make sure the clipboard value is converted from text to numeric using the val( function, like this:
Wait a minute – does this mean that the current field is a text field? I would think this should be a numeric (integer) field. I am really, really surprised on a couple of levels that this code ever worked in any version of Panorama.
Let me reprise (from older posts) the two major reasons why the clipboard should be avoided for calculations like this:
First, doing this clears out whatever value was already in the clipboard. If you Command-C to copy a value into the clipboard, you expect that value to stay there until you use Command-C again (or Command-X). Using the clipboard for a calculation breaks this feature of macOS.
Secondly, the clipboard is waaaaay slower than using a Panorama variable – like 100x slower. There’s a lot of overhead in accessing the clipboard from macOS. For this short program it doesn’t really matter, you wouldn’t notice the speed difference, but if you ever used it in a loop you would really notice. So it’s a good habit to avoid it.
The only time I would recommend using the clipboard functions is when you specifically want to interface with the Command-C, Command-X and Command-V keys.
I finally got around to testing this. If I run his original code, which uses copycell, in Panorama 6, and the field is a text field, I get a type mismatch error. In an integer field, I get a number that is one greater than the number above.
In Panorama X, in a text field, the cell above contains 1000. The result is 10001. In an integer field, the cell above contains 10. The result is 101. So it appears that Panorama 6 knows when it has copied text, and when it has copied a number, and the clipboard() function returns that same datatype. In Panorama X, the clipboard() function always returns text, regardless of the datatype of the value that was copied.
I have run into other places where Panorama X has treated data as text where Panorama 6 treated it as numeric.
One was particularly troublesome, because it was in code that controlled a dialog. The error froze the database at that dialog, so I could not get out of it without force quitting, with other changes that I had not saved. Fortunately I could open windows with the changes, copy them to TextEdit, and restore them after I forced Panorama to quit.
No, it is a number (now integer, formerly floater). BTW, Dave’s code works great. More entertaining these days with the color hiliting and the Mac’s bouncing/zooming updating display.
