Two central fields in my entry form, both date type, are returning the error message “Filed or Variable [Out] does not exist”. («Out» is when the invoice goes out and «In» is when the payment arrives.) Yet both fields take input without complaint in the Sheet. The form and the sheet contain the same info, and I don’t see field attributes in the form’s attributes panel that would cause an error in the form but not the sheet.
Except that in the form’s attribute panel are items more pertinent to a text field than a date field, such as word-wrap and capitalization.
That doesn’t give you the error message he quoted. If I create a variable with the same name as a field, no error appears, I just get different values showing in the form and data sheet. The data sheet shows the field, and the form shows the variable.
I can get the error message if I misspell the field name in the form. For example, I could capitalize it in one place, and make it all lower case in the other.
No, I actually have yet to create a variable in a procedure in PanX, I’m spending so much time trying to get old code to work. If, back in v6 I’d made that kind of mistake, I wouldn’t have experienced 25+ years of flawless performance.
I did check in the Search panel, for an appearance of the word “Out” in any of the procedures I’d been mucking with. They were all properly spelled and ready to interpret as field names.
The best I can say is the trouble starts when I’m tabbing out of «Out». If I try to reactivate the field TEobject, it locks up all the others up. Then at various times, when trying to tab out, I’ve had these two alerts thrown at me.
If I somehow can get into the next field («In»), Tab acts as if it’s in a text field, moving the insert point 1/2” to the R with each tab.
(BTW, the «Age» figure is calculated in days, for an invoice which is still waiting for its «In». Here apparently, with data in the «Out» field and an empty «In» field, it figure that that bill has been outstanding fro 6738 years.)
Nothing in Code. There are other fields which would have formula/code, but not this one. «Out» is used in the .Initialize to update the age, but our problem is one at the point of input.
If you want, I could post a screen recording on DropBox.
This error message can only occur when some code is running. Since the error message only appears when you do data entry in the form, the code that has the problem must be in the Text Editor object itself. You need to look in the Procedure panel associated with the Text Editor object.
The only Procedure panels with any code are 1.) look-up code in the «CUS ID» TEO, and 2.) in the «Out» TEO, something added recently to display whatever error message initially occurs, tabbing out of that field: if error message info(“error”) else message “OK” endif
1.) has yet to work
2.) with that (troubleshooting) code removed, in fact all code/formulas in the TEOs and the Sheet’s Properties’ pane, the problem persists.
I get the same results whether the input is done in the sheet or in a form. Which makes sense because there is no separate code for the form.
This database contains a .ModifyRecord procedure. This is the code that is running where the error is occurring. When working on a problem like this, you need to conduct an exhaustive search for all code that could possibly run.
Here are the first few lines of this procedure.
if info("FieldName") = "Out"
local lvlastserve, lvwho, lvwhat, lvUpdate
lvlastserve=grabdata("WBPS Accounts Receivable",Out)
lvwho=grabdata("WBPS Accounts Receivable",«CUS ID»)
lvwhat=grabdata("WBPS Accounts Receivable",Category)
Since Out is mentioned a couple of times in this code, I suspect that is the source of Out in your error message. However, this did not produce an error for me (once I renamed the file).
When the file was sent to me, it was named WBPS Accounts Receivable copy. Did you give it that name before you sent it to me? Or were you using it with that name. With that name, the code failed on line 3. However the error message was that the database wasn’t open – the name Out wasn’t mentioned.
Once I removed the suffix copy from the filename, that code worked fine. It did fail later when it tried to open a file you didn’t send me.
By the way, I don’t think the grabdata( functions are necessary at all. I would suggest
let lvlastserver = Out
let lvwho = «CUS ID»
let lvwhat = Category
Much simpler, and then the database name doesn’t matter.
At the bottom of this procedure you use the right statement. This will not work in a form, never would have in any version of Panorama. If you want to change the tab order on the fly, you must use this new method for Panorama X.
This code could never work. The if error statement cannot be the first statement in a procedure. The if error statement applies to the statement above it. Since in this case there is no statement above it, Panorama will ignore the if error statement.
I’ve removed the “.” from the procedure name and the two date fields now behave normally
Also, the specification that it be the «Out» field that triggers the assembly of data is unnecessary if the code is in the field’s property code window. (As to the “copy” in the filename, the only change once the copy was made, was to delete all records except one, for demo purposes.)
Ok, but that’'s the same as completely removing the procedure.
Also, the specification that it be the «Out» field that triggers the assembly of data is unnecessary if the code is in the field’s property code window.
Yes, if I needed code that runs when a specific field is edited I would put it in the field code, not in .ModifyRecord. The purpose for .ModifyRecord is for code that runs for multiple fields, or all fields (which is rare).
As to the “copy” in the filename, the only change once the copy was made, was to delete all records except one, for demo purposes
Ok, but my point was that the procedure won’t run if the database is renamed. I guess you are saying you never ran the renamed database yourself, so this didn’t affect you.
Or simply turning it into a procedure which has to be run only manually. (Lord knows why I chose the .ModifyRecord name, Lo those many years ago.)
I didn’t include the lookup-source db because that wasn’t the problem at hand. The remaining problem (once past the .ModifyRecord clam) is that the choice of which CUS ID to pick when there were multiple customers with the same last name was set up in v6, as a List SuperObject. I’m guessing that v10.x has many ways to skin this grape (because “superobject” abilities are ubiquitous in v10), but that the simplest would be the View-as-List. All I’d need is to highlight (select) the correct choice of LName/CUS ID, to complete the «CUS ID» lookup.
Again, I’m indebted to the helpfulness of this forum.
.