I was just getting erroneous data showing up in a file, where variables are declared in the .Initialize procedure, and then those variables are set in another procedure, which then uses the showvariables statement. Only the last two variables declared were erroneous, so I put in wait(0) after the variables declaration, and everything seems to work okay now. Maybe something like that could be used.
Do you mean that you were seeing error messages in forms where variables are displayed? Since forms are displayed before the .Initialize procedure runs, this will happen if a fileglobal variable is displayed in a form. I’ve gotten into the habit of always using the catcherror( function when displaying variables in a form, like this:
catcherror("",someFileGlobalVariable)
I’ve thought about adding a checkbox to forms that would automatically display blank instead of an error message. (When you actually wanted to see the error message, you could use the new Object Value feature.) This would save the extra typing of having to add catcherror( functions to object formulas.
I’m not following what you mean here at all, so I’m not understanding how the wait statement is helpful for you.
No error message, just numbers that were way off.
I think that the declaration of the variables was not complete at the time that the values for them were computed (aggregate( functions computed). Wait(0) seems to make sure that the declaration is complete.
A variable is either going to be initialized or not. There’s no intermediate point where a variable would have a wrong value.
However, perhaps if an aggregate( function used an uninitialized variable it could come out as a bad calculation rather than an error, depending on where the variable was used. Again, I’d suggest using catcherror(.
Well, all I know is that a couple of the aggregations were not calculated correctly without the wait line, and they were afterwards. The difference was quite substantial in one case, and even after I had corrected it, the correction would not stick through a save. Running the procedure that calculated the aggregate would not correct it; computing it through the Formula Workshop did.
I just think that sometime things get run through multiple cores, and one core may start working before another is finished. I think this is an Apple problem, not a Panorama problem. The wait(0) just insures that things are done in the correct order.
FYI – with one exception (interactive searches), Panorama is single threaded, so it only uses one core.
I am aware of that, but it does not mean that some of Apple’s underlying code is not multi-threaded. After all, there should be some value to having all the cores on my computers. Anyway, adding the wait(0) seems to have fixed the problem.
So tonight I noticed that the wait 0 trick was not working, and the I was getting the wrong data again. There are two summation aggregates which far off, and a sum that relies on the first of these. If I put the formula in the Formula Workshop, I get the proper numbers.
The variables are several of these aggregate sums, plus a couple of sums of these aggregates. One of the latter sums, the overall sum of all the aggregates, is the proper amount, while another sum, the sum of three of the aggregates, uses the amount which is wrong. These variables are displayed in several Text Display objects. After the sums are computed, showvariables with all of the variables is the final line of the procedure.
There seems to be several things that will correct this. Changing the formula in the Text Display object will do that, and sometimes just using the Formula Workshop. But even if it is corrected and I save the file, it is wrong when I reopen it. I am flummoxed!
I just made a few changes, quit, and tried again, and now it is working properly. Again, I am flummoxed.
Since you’ve really only supplied fragments of what you are doing, I cannot intelligently comment on what might be going on. However, if you have formulas in Text Display objects (or any type of object), those formulas may be evaluated before the .Initialize procedure runs (if the form opens automatically as the database opens). The best way I know of to handle this is with the catcherror( function.
I am sorry I cannot send in the file, but it contains gobs of personal information.
What I do not understand about all this is that the procedure that computes what should be in the variables is separate from the declaration of variables, because it is called not just on initialization, but whenever the data is updated. It updates the variables, using aggregate, and then asks for them to be displayed on the form.
The problem is that the display is sometimes wrong, and even calling the procedure again does not correct it.
Boiled down to a single element, the procedure is:
YieldTotal = aggregate("«Annual Yield»","sum")
Showvariables YieldTotal
There are other elements, but they are roughly the same. This is one that occasionally goes haywire.
The formula in the Text Display object is just Pattern(YieldTotal,"$#,.##")
So what I do not understand is how that aggregate is miscalculated, and, given that the Formula Workshop computes it correctly, why it does not change when I run the procedure again, because I can run it separately.
It may be something that happens after I have been leaving Panorama open for a while. I was just reading about memory leaks in MacOS, so something like that may have something to do with it.
Anyway, it cleared up when I made a change in the procedure, after quitting and restarting Panorama. I will keep an eye on it.
I think this is an important clue. I think what is happening is that somewhere you are setting up YieldTotal as both a global and a fileglobal variable, and these are conflicting. When you quit and restarted the global variable went away, so it worked. Then at some later point you are running the code that creates the global variable again and you see the problem again. This would also account for the wildly wrong value – it’s a value that was calculated somewhere else and I’m sure is perfectly valid for whatever the calculation was.
This is why I strongly encourage keeping the use of global variables to an absolute minimum. If you can figure out a way to avoid a global variable, you should do so even if it’s a bit more work. If it absolutely can’t be avoided, at least make sure that each global variable has a distinctive name that you would never use anywhere else.
Now you are going to need to figure out where else you used the YieldTotal variable. The View Search window can help you with that, but it might be a bit tricky because it could be in any database, and the View Search window won’t search a database if it isn’t open. Happy hunting!
That isn’t always necessary, and in this case I’m glad you didn’t. It would have taken much more work for me to wade through your code. You sent in exactly what I wanted – a succinct but fairly complete description of what you were actually doing, which was quite different from what I had imagined (I was thinking that you put the aggregate( function directly into the Text Display object.)
That was it! I had a couple of files for some other accounts that, being simpler, I had taken a bunch of things out, and used global instead of fileglobal. Thank you!