Okay, maybe it isn’t and I am just going crazy here, but look for yourselves and judge:
--> Running the preprocessing script
on sRunPreprocessing(lUserName, this_folder, lScriptsFolder, gPrefsFolder)
try
set z to 13 -- Block marker
if ((current date) ³ (pPreProcTime + (30 * minutes))) or (pPriorityNo = 0 and pGeneralNo = 0) then -- 30 or more minutes or no other jobs in queue
set LoadPreprocessing to load script alias (lScriptsFolder & "Preprocessing.scpt" as Unicode text) -- Load Preprocessing script
tell LoadPreprocessing
sPreprocess(lUserName, this_folder, lScriptsFolder, gPrefsFolder) -- Run preprocessing script for next in queue
end tell
set pPreProcTime to (current date) -- Reset the clock to now
end if
on error msg
my sMyErrorLogger(gY, z, msg, lScriptsFolder)
display dialog "Error location " & gY & "/" & z & ": " & msg with icon stop
end try
end sRunPreprocessing
The error I keep getting is that the variable z is not defined. Buh what? Maybe I am wrong but I specifically put set z to 13 as the third line in the script to define z as 13. Did my upgrading to 10.4.10 somehow cause a problem or am I missing something elementary? I do not get this at all especially since z only comes into play when an error occurs but strangely enough the value 13 IS getting passed because it is showing up in the error log. How can 13 be passed to the error logging script if z is not defined?!?
I can post more of the scripts involved but I must warn you, the main one is very large.
I wonder, now that I have had time to reflect, if this is somehow related to the problem I have in that every time I shut the computer down or restart it all of the folder actions are lost. It’s not logical reasoning I know, but a defined variable giving me a not defined error doesn’t make any sense either.
Is there perhaps a z that’s being accessed but not set in the loaded script? If there is, the error might be about that rather than the one you’ve set to 13.
I have not tried putting it outside the try statement but will when I get home. As for the possibility that z is being accessed but not set - I’m not sure I understand. As a point of reference, I only use the variables gY and z in all of my scripts (right now this project is using 17 of them) as a script designator (something to indicate which script threw any given error) and a block indicator (which tells me the location of the offending subroutine) respectively. When the error is logged it is indicating that it is my Queue Management script throwing the ‘z not defined’ error in subroutine 13 (on sRunPreprocessing()). I have also been combing through the error logging, user inbox, preprocessing, and text editing scripts to see if there is a problem originating with any one of them but can’t imagine how it could be since the error log itself is indicating the Queue Manager.
Maybe this isn’t Applescript at all. I am considering reformatting my Macs harddrive and re-installing everything at the end of this month because of various buggy behavior including the fact that my folder actions keep detaching themselves after a reboot and I have a corrupt FontBook application. Who knows what crap lurks in the OS after a few botched unix installations and several software installation and removals?
I mean that the only thing I can think of that would give the effect you describe would be if the “z is not defined” error was actually occurring within the loaded script ‘LoadPreprocessing’, but wasn’t being caught there. The error would then be passed up to and caught by the ‘try’ block in your sRunPreprocessing() handler. The error message would be “z is not defined”, but the local z within sRunPreprocessing() would be defined and its value of 13 would be passed to your sMyErrorLogger() handler.
To put it another way, your error log shows where the error’s being caught, not necessarily where it’s being generated.
Sorry it took so long to reply to this. Since I had been stuck I went on to work on another portion of the project and now that it is finished I came back to this. As it turns out Nigel you were spot on, the preprocessing script was throwing the error and I discovered that my error logging system has a project-wide flaw with the z variable (or at least how it can throw a misleading location). Not only have I fixed the problem generating the error but have gone into all of the project scripts, fixed the z variables, and rewrote the error logging subroutines.
