FileMaker Pro or FileMaker Pro Advanced?
Is the field 'Number' of the type number? What are the storage settings of this field?
Are there any script triggers active?
Has the field on the alyout any conditional formatting applied?
Etc. etc. Give us all the specifications that apply
Filemaker Pro 10 Advanced 10.0v3
Quadcore PowerPC 10.5.8
Field is type number.
Storage, not global; indexing none (I rarely need to search on this field).
Select entire contents when entered, sychronize with field's font, no visual spell-checking.
No script triggers whatsoever.
So all seems in order.
Since you have Advanced, I suppose that you have script debugging and data viewer activated. If not, you should.
Then you can monitor the process:
Is the variable $mynumber correctly set before the script step 'Insert Calculated Result' is about to run? BTW, you should use 'Set Field'. instead of this step.
I understand that the value appears in the field, but disapperars the moment you commit the record.
Experiment with the script step 'Commit Record'
Also, when debugging, add the script step 'Exit script'. This gives you the opportunity not to finish the script while debugging and you still can see the content of the variable(s), fields etc.
I'm curious about this phenomenon. Could you post the file?
I'm assuming the variable is set correctly, since it is inserting the number given by the user into the field.
I tried several versions of the script with Set Field rather than Insert Calculated Result, but it inserted nothing in at least two different versions. At least with ICR the number showed up.
I've written many scripts (always with much frustration and gnashing that I don't experience with other scripting tools) and sort of get them working or working with workarounds and I haven't seen this particular quirk before.
I'm dead tired, but I will try Commit Record, will experiment more with the scirpt debugging (I had the debugger running at first, but it was doing strange things too, so I turned it off) and will report back after I get some sleep.
The script debugger is indispensable. When strange things happen probably something is wrong with your script.
I find the FileMaker scripting very easy and straightforward. I think you can accomplish anything with it.
Please upload the file, I will have a look.
Sleep well. What's your time zone? I'm in Western Europe. Just woke up.
N.A. west coast here.
"I find the FileMaker scripting very easy and straightforward. I think you can accomplish anything with it."
I must have the wrong mindset for it. I can write scripts in CGI, perl, BASIC, C, LISP, and a bunch of other languages and frequently get them working the first time (no debugger or debugging needed) and yet I struggle constantly with even the simplest Filemaker scripts.
Well, I'm not fully awake yet, but I tried adding a Commit Records/Request at the end (without changing anything else) and it wipes out the data the same as clicking wipes it out after the script has run. The field goes blank.
The same thing happens if I add Exit Script at the end instead of Commit Records/Requests.
Out of curiosity, I also tried adding Go to Next Field at the end of the script and that also causes the field with the inserted variable to go blank.
I'm not sure I can upload the file. It's a proprietary line items/sales/invoicing/inventory with many relations. It would be difficult to pare it down without changing the dynamics and giving a skewed picture of what is happening (or giving away company information).
I'm perplexed as to why committing a record (by script command or by mouse click) would remove data (in this case a number) that's been inserted into a field. I haven't set any script triggers at all.
"I'm perplexed as to why committing a record (by script command or by mouse click) would remove data (in this case a number) that's been inserted into a field. I haven't set any script triggers at all."
This indeed is not normal. I could propbably solve it if I could get my eyes on the file. Maybe you could just make a test file with a field and the same script. But I guess that would probably function as expected...
How are you getting the variable information from show custom dialog box ? This option only allows you to store data to a field. Unless you are getting which button was click then you would use Get(LastMessageChoice)
You should just use the field Table1::Number as your input field in your custom dialog box.
But J Petersen clearly states that the value is visible in the field and then disappears upon commit. I presume that transport from custom dialog to the field has been done properly.
You can not assign a value to a variable in a show custom dialog box. You can assign a value to a field. Data just doesn't disappear, unless you have a corrupt file. There are items that are incorrect in the script, which, I can not make suggestion about without seeing the script. I would guess that he is not displaying a field but displaying the variable and that is why the data is disappearing.
It's hard to state what the problem is without know more about the application but data could just appear that it is disappearing because of the relationship that is setup. If the data is being inserted into a field which makes the relationship fail then the data would disappear from view, but would still be in the database.
"If the data is being inserted into a field which makes the relationship fail then the data would disappear from view, but would still be in the database."
If I manually insert the number directly into the field (let's say 1236 is typed in without using a script), it stays (remains visible). If I use the button to launch the script and ask the user for the number by using the custom dialog box, the user types in 1236 and the script inserts it into the field. Up to this point both methods have the same result, you can see the number 1236 in the field.
If the number is inserted manually (directly into the field) and you click anywhere else, the number remains.
If the number is inserted via the script shown in my original post and you click anywhere else, the field becomes blank.
it's the same number, and the relationship is valid (yes, this number is related to another table), so it's hard to understand why one might remain and the other might fail.
So it's clear: the script sucks. Corruption not likely.
I suggest you show us the script, the real script, not the pseudo-code in your first post
Go to Layout ["Inventory" (Inventory 11)]
Show Custom Dialog ("Get Transaction Number"; "Enter transaction number: "; Inventory 11::NumTransact]
Insert Calculated Result [Select: Inventory 11::NumTransact; $numtransact]
The intention is to add error checking to make sure the user has entered a valid (existing) number, but I couldn't see any point in adding it until I have a basic script that inserts a number (and leaves it there).