Since you are pulling up a list of "late" members, would not logging a payment remove them from the report?
if that's the case, then you have to re-run the script to omit that record.
Yes, I too thought that removing the late payment would update the payment status in the report but it doesn't
So, I tried rerunning the script [with the report window open] and it doesn't refresh the report window either.
However, when I first open the report it accurately picks up all the late members from the membership table
I'm afraid that I didn't make myself clear.
What update are you expecting to see in the report?
Are you expecting to see the member for which you have logged a payment to drop off the report or something else?
Yes, I am expecting to see a member that was designated 'current', to drop
off the (Late Payments) report.
Two things are required:
commit records in the window where you changed the member's status.
The record must be removed from the found set in the report window.
Performing the find and sort again in the report window is the simplest way to do the second task.
The problem is that using any script trigger to cause the report to 'rerun' (after a change is made in the main window) causes FM to hang when it encounters PERFORM FIND.
ie, when i use either On Record Load or On Layout Enter.
I suppose I could attach a script to the main window that would determine if the report was open and if it was then close it. This would cause the user to reopen the report thereby running the Find without a problem.
But, doesn't it seem weird that FM gets hung on the PERFORM FIND????
I think you have a script that is tripping it's own script trigger and thus getting trapped in an infinite loop.
Example: If you use OnRecordLoad to perform a script that Performs a Find, performing the Find trips OnRecordLoad which Performs another find, which trips OnRecordLoad and so on...
Opening a new window, trips both triggers.
Stepping thru your script in Advanced's script debugger would show the scripts "stacking up".
There is a way to prevent that, but I'm not convinced that you should be using either trigger to create this report. The only trigger I might use would be a trigger on the field you edit to change a member's status.
That said, I put this code at the beginning of every script performed by a script trigger:
If [$$TriggersOff ]
Exit Script [. ]
In every script that is going to trip script triggers that I don't want to do anything, I add this step:
Set Variable [ $$TriggersOff ; value: True ]
before the first step that would trip a trigger and then this step before the script exits:
Set Variable [ $$TriggersOff ; value: "" ]
Thanks for the thoughtful reply.
"The only trigger I might use would be a trigger on the field you edit to change a member's status."
I thought of that but the drawback would seem to entail knowing 'which' report window is open so that the proper sort / find can be performed. To that end, I see a stand alone script that would do If/Than not is empty "Window Name" listing all 49 of my reports. Within that structure I would nest the appropriate sort/find. This seems like 'the hard way'.
Also, in evaluating this situation, I noticed this:
I have 2 reports: 'Current and Late' and 'Late'
Current and Late is a sub summary.
Late is not.
The Find and Sort codes are the same.
Both are based on the Members table.
But, Current and Late updates when a change is made in the main Members window.
Late DOES NOT update when a change is made in the main Members window.
So, I add a sub-summary feature to Late. (But leave the fields therein blank) IT does not change anything.??
I am perplexed. This kind of 'window refresh' should be a well known technique in FM. Or, am I the First to notice there is no 'elegant' way to affect this update?
Here is the Current or Late script:
Here is the Late script:
Thanks for your thoughts.
If you need to omit a record from a report's found set, no amount of "window refresh" as in the script step of that name will do anything to omit that record.
I thought of that but the drawback would seem to entail knowing 'which' report window is open so that the proper sort / find can be performed.
I would use a script to open that window and produce that report in the first place. To update your report, you run the script again. The script can use filtervalues to check the list returned by window names to see if a window with the specified name is already open. Note that you've only described one report that needs this update so it's not clear why you would need to check a list of 49 different window names just to update one or two connected with showing which active members are "late".
But I also spelled out an alternative that can be used to keep a script trigger performed script from trapping itself in an endless loop by tripping its own trigger.
When I look at these two scripts, there's a lot that doesn't make sense and since you are dealing with an issue that is equal parts layout design and script design, just showing me the scripts doesn't really help much.
Steps that make no sense:
Using filter values to compare the file name of the current file to text in quotes and creating a window with the text in quotes if the file name does not match. Not only could the expression be simplified, I don't see the point in doing that.
Showing all records just before performing a find does nothing You can remove such steps and a find will produce the same results as before.
Neither Commit Records, nor Refresh Window should be needed at the end of the second script. Any record commit would be needed in the other window where you are editing data to change a members "late" status. If you needed the member record to stay in the report but values in fields of that member record need to show the new status, then refresh window--in a separate script that selects, then refreshes the window might be useful.
And your first script performs another script about which I know nothing.
There is nothing in either script that would have anything to do with omitting a member record that was just updated to no longer be "late" in another window unless, after making that change, you ran the script again which might trip script tirggers set on the layouts for those reports.
First I added the commit and refresh window in acts of 'desperation' 8-) . Same with Show all. I figure even though they were redundant and unnecessary if I specified them in the exploratory phase I would know they got executed.
Here is something I didn't know.
The Current or Late report is a sub summary report consisting of two 'sub summary' bands: ::DuesStatus and ::MemberName. This is the report that, when the main window changes the dues payment, automatically updates to show the status. By that I mean if the current membership year is Jan 1 2017 to Dec 31, 2017 and a late member makes his March 6, 2017 payment, the program updates his ::DuesStatus from "Late" to Current. This report works as desired.
The 2nd report is the ::DuesStatus="Late" report. It does not have a SSumm band and it will NOT update. (It WILL if I add a SS band and put the ::DuesStatus in that band and sort accordingly.) The problem with this is that doing this includes the CURRENT as well as the Late Members. I want just the Late members.
Doesn't it seem weird that FM works that way? The reasoning for this to work this way eludes me. Got ideas?
1 of 1 people found this helpful
"This report works as desired."
There is a difference between updating a value in a field listed in a report and omitting a record from the found set. This is something that I have stated repeatedly. In the report that updates correctly, you just have a field that needs to display updated information.
It sounds like the second report has to omit the updated record before it can update correctly--this is what you told me previously, anyway. That kind of "update" requires a script to do that. Neither refresh window nor commit records perfotimed in the report window will do that.
Nothing weird about that.
It looks like I am left with two choices:
a) create a script that holds an if/than evaluation that determines if a report window is open. If it is, it runs the appropriate script. (Lots of reports with possible windows open but it can be done)
b) put a 'REFRESH' button the report that calls the same script that opened the report. This would update the report but would take some 'explaining' to the end user.
It seems to me this entire situation could be mitigated if FM would implement a 'Layout Focus' script trigger that would fire whenever the layout gets the focus (from the main window. )
As usual, your ideas are illuminating and much appreciated.
1 of 1 people found this helpful
Report windows should be opened on demand, and closed when no longer needed. The report can only show the data available when the report was generated.
Make sure each report window has a unique name. If the report window is already open, close it and generate the report again.
If the accuracy of the data is mission critical, consider making the report window modal, which will force users to close the window before doing anything else, so they cannot leave it open. (Note that I don't like modal windows, I avoid using them.)
Modal! Excellent idea.