Jump to content
Server Maintenance This Week. ×

Local Variable held from previous session


This topic is 2226 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I have a situation that I've never seen before.  

Mac OS 10.13.3 and FM Advanced 16.0.5.500

In a script, I had been setting a local variable called: $hours.  As I was debugging part of the script I noticed that the $hours was being set as soon as the script was triggered - in Debugger not a single step was executed yet and somehow the $hours was set.  I've tried everything I can think of and yet in that script $hours is still being set and the worst part is the value is not editable.  Can't overwrite it with a script step, can't manually change it - nothing.  I've deleted prefs, cache files, everything I can find that has filemaker in the the name in my User/Libaray folder.  Restarted.  Etc.  It must be tied to v16 in my profile on my machine because this does not happen at all on v14 of the same machine nor on my PC.  I'm just baffled as to what file on the computer is holding that information and how I can make it go away.  Next step is to completely un-install v16 and start over there I guess.

I've changed the script to use a totally different variable now to ensure the script executes properly, but would love to solve this mystery - I'm a little worried that if this were to happen on a client machine they would get bad data when executing scripts.  Anyone see anything this strange before?

Link to comment
Share on other sites

I can - but the strange part is - I have completely removed the $hours from the script altogether - and still in Debugger that variable appears as being set.  So while I can show you want the script looks like now - that variable doesn't even exist in the current iteration of the script.  It's totally strange... Been working in FMP for about 20 years and never seen this one before.

Link to comment
Share on other sites

I wasn't fixated on the $hours step, I was more interested in seeing what other steps were in the script also.

I ask about AS ( AppleScript) in the script, because there was a change the Security, Privileges 16.

Could you copy the one used for v14?

AS in Edit Privileges.png

Link to comment
Share on other sites

Gotcha.  No AS at all in this.  It's a very basic script to gather vacation time tracking and process it.  For some reason I can't paste the script code into this post.  But it's really nothing other than setting some variables, doing a little math based on those variables and creating (or not) a new record.

And again, this isn't so much for me about solving this script - I have lots of ways around that - it's more about why my machine seems to think that variable still exists and ensuring that goes away.  Somewhere on my machine is cached data that is not getting flushed.  It makes me wonder what other types of info might get "stuck" like this with other solutions.

I do appreciate the help though!  Thanks!

Link to comment
Share on other sites

I'd suspect something else then. Some conditional formatting or hide calc, some ill-written custom function, even your data viewer watch functions; something is declaring that variable.

The fact that you can't post a full and complete script - is also troubling.

Have you got Advanced? Can you generate a DDR?

Link to comment
Share on other sites

First - thanks all - I really do appreciate the ideas.  I've been developing in FMP since v5, about 22 years ago and spent 10s of thousands of hours in it.  This is a first for me.  

While on the surface it feels like it's something getting set along the way, I do not believe it's anything in the database itself that is causing this issue - nothing in startup script, or custom function or even data viewer are setting the $var.  

With data viewer open (yes, we develop in FM Advanced) - prior to triggering the script in question I only have the $$vars that are set in startup script.  As soon as the script in question is active - although no steps yet executed - the $var appears - again, zero steps actually completed, just open in Debugger waiting to step through.  And the $var in question isn't even part of the script itself any longer either - yet it still shows in Data Viewer as a $var with a value being set...

On top of it - I've checked multiple machines, user accounts, etc. and still, only my v16 install on my Mac displays this behavior.  Same Mac with v14 is fine.  My PC with v16 (also FMPA) is fine.  Other user's machines, fine.  Clearing out all my preferences cause Data Viewer to be reset (among other things), nothing.  Stepping through scripts on all machines show nothing.  It's truly odd.  If it were in the database somehow I'd have to believe that I'd see this behavior on another machine or version of FMP somewhere.  And by clearing all prefs (which clearly did happen) I'm intrigued by what file I'm missing somewhere on the system that could possibly be holding cached (or otherwise) data about this script and $var.

And I know you'd like to see the script steps themselves, but I promise it's nothing special.  Sets a handful of other variables (dates, etc.), checks a value of a couple of fields and depending on those values would eventually set the $hours variable.  At this point I've removed that $hours altogether from the script - it's now $vacHours - but still, in only my v16 install, script debugger & data viewer show $hours being created immediately and the value is unable to be edited.

I'll likely chalk this up to some odd quirk and move on.  Again - in all my years of working in FMP I've never seen anything like this.  I'd just love to figure out what it is to ensure it doesn't occur on any other client systems.

Edited by eswanborg
Added info about script steps.
Link to comment
Share on other sites

Yes, immediately - no steps executed.  Just by calling it.  And I wish it were a script parameter but it even happens from the Script Editor where there isn't a Script Param to pass in... 

Link to comment
Share on other sites

Good thought - but I tried this:  deleted all the plugins (we do use SuperContainer and ScriptMaster) and restarted FMPA.  I opened the database in question without letting any of the startup or other scripts fire.  Even then (with virtually nothing loaded) I get the same result.

Link to comment
Share on other sites

This topic is 2226 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.