There are context limitations on the results returned by both functions. In a script, Get ( RecordOpenState ) only references the current record. The other function only references the current found count--which in turn is limited to only the current layout and window. So records could be open in another window or layout and they would not be counted.
That's helpful, but it doesn't explain why my one statement test script works and the other doesn't, right? Also why would the watch window display the correct result and not the script when both are contemporaneous. Wouldn't that mean they are in the same context?
Maybe the auto copy script is changing the context somehow. So, the right question is, what in the script would change the context and how can I prevent that? There is another script that performs this script when the timer pops, but performing the Timed Autocopy script is the first statement in that script. Could referring the global $$RecordCommitted be changing the context? Doesn't sound right to me, but I clearly don't understand all the implications of the term context.
Or how do I find out what the context is? Then I could check it with both the scripts. Still very confusing to me why the watch expressions would be correct and the script not.
I am also noticing in the functions ref that it says something about specifying the context for the current calculation. How do you specify that? Maybe that would fix the problem?
TIA for your help on this.
That's helpful, but it doesn't explain why my one statement test script works and the other doesn't, right?
It might as the context might be different. I couldn't tell from your previous post. There could very well be a bug here, but some of what you posted seemed to ignore possible context issues so I supplied some info to, hopefully, help clarify that detail and to help rule out context limitations if that's not the source of the discrepancies found.
"context is determined by which layout of which window currently has the focus in your script--and is further constrained by that window/layout's found set and current record. For a calculation field, there's a "context" drop down that specifies the context under which the calculation will evaluate.
If used with the debugger, I would expect the context and thus the values returned, to be the same for a watch expression and an unstored calculation defined to evaluate in the same context as the current layout. A value in a variable that is assigned the result of one of these functions should match at the moment the set variable step executes.
Thanks again, Phil
There has been no change of context in terms of found set, window, layout or even the point in the field and record that the insertion point is in, so the context is the same for all of these situations. Nor has the record been committed in any of these cases.
I appreciate the info on context within a calculation. Good to know for the future. In this case no calculation other than the get functions is involved and I didn't even know you could change context there, so that can't be causing the problem.
So, I think we are agreeing then is that this is an FM bug.
Is this thread considered a sufficient bug report or should I do something else to enter it into an FM bug list?
What I am waiting for is a response from a TS person either indicating that either the issue has already been reported or that they can reproduce the issue in their own tests. At that point, the issue is logged in FMP Inc's internal system and then add it to the public domain of known bugs in my database.
Please note that whether or not a bug is listed in the KBL, and the risk level assigned to it has no affect on when or if FileMaker inc will correct the bug.
So frustrating to us customers, isn't it, to spend a lot of time to research something like get ( RecordOpenState ), to code it, test it, find it doesn't work as advertised after hours of trying to make sure it isn't us, report it, and then to learn that the product failure/error will possibly languish in some ignored pile of bug reports. Frustrating for us customers who pay for a product to work as documented. Frustrating, isn't it!
It must be frustrating for you as well to have to pass out that disclaimer over and over. I appreciate anything you can do to push it forward. I'd really like it to work or find out what I am doing wrong.
Once, again, thanks for the information and update, Phil. I really appreciate your efforts. Please, let me know anything that might inform me of what is going on or how I might follow up.
I am not the least bit frustrated over that disclaimer. It's simply clarifying that the KBL is a public, community supported list, not a product of FileMaker Inc.
I updated the KBL to close over 60 different bug reports when FMP 14 was released and have encountered info that a number of other bugs that never made it into the KBL were also fixed with that release so it is clear that FMP Inc. doesn't just leave them in an "ignored pile of bug reports".
Thanks again, Phil. Glad to hear that things do get fixed. Is there a way to track the progress of this particular problem?
All you'll get, eventually (the new release of 14 has them running about a week behind in responding to bug reports according to a post by TSGal), is a response from TSGal either confirming that they can reproduce the issue or that they cannot and want more information from you, up to and including a copy of a file from you that illustrates the issue. Once they confirm a bug, you hear nothing more until a new release of the product fixes it and then you may get a response here indicating that the new version corrects the issue.
Thank you for your posts.
From the screen shots, it is difficult to determine when and where the values are examined. For instance, I don't see where $$RecordsCommitted is initialized. What is the active layout and the table associated with that layout? Is it the same as the "Timed Auto Copy" layout and table?
The left side of your screen shot shows the Data Viewer with Current tab selected, while the right side shows the Data Viewer with the Watch tab selected. Place the variables in the Watch tab so you can then see the values simultaneously.
If you have a way to replicate the issue, then send in your database file. Check your Inbox at the top of this page for instructions where to send the file.
I know a lot of time has passed, but Testing is investigating this issue now. They have requested a screen recording to understand how the second window is being opened. My notes don't specify much, so if you could remind me of the steps to replicate the issue, I'll make the screen recording.