Call script with delay problem

[Powerslave]

Hey everyone , I have just purchased Scriptmaster in the hope that the script timer function would perform a few tricks for me , but I'm stuck.

Firstly , I'm using FMPA11 on windows 7 64bit , Java Runtime version 1.6.0_24.

I am having a few problems so maybe some here can help me.

Firstly , when I use the ScriptMaster.fp7 file to test the CallScriptWithDelay external function , it does not trigger the script after the specified delaySeconds value. EG:

fileName = ScriptMaster

scriptToRun = TOC

delaySeconds = 20 (or 5 or anything else)

The resultcode of these tests are always "1" , which I think means no error.

The script does not trigger after the specified time. However , if I test the function a second time , the first trigger I set then executes immediately. If I wait , the script will trigger up to 5 minutes later !. It's like the stack is being held up or something.

After creating the plugin as a .fmx plugin and building into my own application , I get the same result as testing in ScriptMaker.fp7.

Secondly , when I use the CallScriptAtScheduledTime , I get an error saying that the date is unparseable , even If I use "M/d/yyyy h:mm:ss a" format (9/14/2011 11:11:58 AM for example)

Is there any "in depth" documentation on these functions as the user guide does not really explain each function in any detail.

Thanks in advance.

[Cabinetman]

Well. on the delay. Mine works fine.

But then again I don't see the external function part....

 

int delayMilliseconds = Integer.valueOf( delaySeconds ) * 1000;

new Timer().runAfter( delayMilliseconds,

 {fmpro.performScript(fileName,scriptToRun)});

return true;

[marek]

I have similar problem with this function on Mac.

For time=0 it triggers immediately, but for any time >=1 there is very long time of waiting for trigger (independent of the value of time parameter.

[epeeler]

I just spent a little while testing this myself and I didn't have any problems. Could you please send a bug report the next time you make it happen so we can look at what's going on behind the scenes.

[marek]

the problem is there is no error or any comment of bug reported anywhere. Immediately after run script with delaySeconds=1 script is started (there is 1 in the result text). There is nothing returned to Console and nothing is happened before 1-5 minutes after run script. Computer an SM file is working (not hanged). And after few minutes script is triggered - not after 1second declared (or any longer time).

[marek]

I checked it once more on completely new dowloaded SM. First few runs with delaySeconds=1 worked fine. Then after changing to delaySeconds=5 each time delay was different. Script was triggered after 1 second to over 60 seconds. It doesn't depend if function is registered or not. I could fin nothing in log files. Also nothing was shown in java console.

[epicmar]

I too have never been able to get the CallScriptWithDelay function to trigger reliably. Even after a fresh restart of Filemaker and launching the included ScriptMaster.fp7, clicking "Run Script" will cause the "TOC" to appear close to the expected time the first time I run it, but a subsequent click of "Run Script" will not cause the "TOC" to pop up until I click "Run Script" again, and then the "TOC" appears immediately, followed by another copy of it shortly thereafter. I get identical results to this when using this external function within my own Filemaker files. (I have also had no luck getting Call Script at Scheduled Time to trigger in a timely manner either.)

I am testing with FilemakerPro 11 Advanced, running in Windows 7 Pro 64bit, with various other 360works plugins installed too.

[marek]

I found that timer part of this function is working correctly (it's starting very precisely). The problem is with fmpro.performScript evaluation. I modified little bit original code and added "println" with times of each event to see where problem exist:

def timer = new Timer()

def task = timer.runAfter(Integer.valueOf( delaySeconds ) * 1000)

{

println "Timer started at: ${new Date()}."

fmpro.performScript(fileName,scriptToRun, param)

println "fmpro executed at ${new Date()} after Run Script."

}

println "Run Script started at: ${new Date()}. Task fmpro should be executed at ${new Date(task.scheduledExecutionTime())}."

return true

The behavior of this function is the same as original SM fuction. There is attached Console Messages log file with 3 runs of the function:

1. After run the script with delaySeconds = 0;
   Run Script started at: 10:44:34. Task fmpro.performScript should be executed at 10:44:34.
   Timer started at: 10:44:34 - as declared in delay time.
   fmpro.performScript executed at 10:44:34 after Run Script - as declared in delay time.
   
2. After run the script with delaySeconds = 1;
   Run Script started at: 10:44:53. Task fmpro.performScript should be executed at 10:44:54.
   Timer started at: 10:44:54 - as declared in delay time.
   fmpro.performScript executed at 10:45:31 after Run Script - 37 sec after previous command println.
   
3. After run the script with delaySeconds = 5;
   Run Script started at: 10:53:10. Task fmpro.performScript should be executed at 10:53:15.
   Timer started at: 10:53:15 - as declared in delay time.
   fmpro.performScript executed at 10:56:05 after Run Script - 2 min 55 sec after previous command println.
   

As we can see above, in all cases timer is starting pretty nice, at declared delaySeconds. Then should be executed next line - fmpro.performScript without any additional delay. It runs as we expected only, if delaySeconds = 0. If delaySeconds > 0 evaluation of fmpro.performScript is "blocked" or "hanged" somewhere in most of runs. The behavior is the same after registering the function and after including in generated by SM plug-in.

If I Run Script during waiting for fmpro.performScript execution, "hanged" step is executed immediately - looks is "pushed" by next execution of the function.

FM SM timer Console Messages.log.zip

[marek]

I just spent a little while testing this myself and I didn't have any problems. Could you please send a bug report the next time you make it happen so we can look at what's going on behind the scenes.

I sent a lot of proof about existing problem in SM ADVANCED (not free aplication) in my last 2 posts. It seems 360 Works staff has no time to help his customers, or even put information that they are working to solve this SM (fmpro.performScript) bug.

I'm wondering there is not any answer yet. I'd like to know if developer is solid before payment for next year of Advanced licence.

[andries]

You don't need the advanced license to use the fmpro.performScript() method.

But I can confirm this behavior...

But not sure if it is the fmpro.performScript() method, or the fact that we put it on a different thread and that the fmpro object is "blocked" by the main thread... I am new at multithreading... so I will not be able to give you the final answer.

I saw an older post when Dan Smith replied regarding this behavior, so I hope he will read this and come to save us

I tried to create a new fmpro object from the FMPro class, but this throws a nullpointer exception when calling the method performScript().

import com.prosc.beanshell.FMPro;

fmpro2 = new FMPro();

try{

fmpro2.performScript("ScriptMaster_4.0.fp7","test" )

return "ok";

} catch ( Exception e ) {

return "error " + e

}

 

[marek]

Andries, thanks for post, but I can't fully agree with you:

You don't need the advanced license to use the fmpro.performScript() method.

It's needed to make your own plugins

But not sure if it is the fmpro.performScript() method, or the fact that we put it on a different thread and that the fmpro object is "blocked" by the main thread... I am new at multithreading... so I will not be able to give you the final answer.

I'm sure - first "println" of attached earlier function is running in expected time. Next line (fmpro.PerformScript) is blocking itself and the rest of lines. It's confirmed by attached Console messages.

I saw an older post when Dan Smith replied regarding this behavior, so I hope he will read this and come to save us

I hope also. I checked his oosm_ScriptCron functions from ScriptMaster_oo file, but there is the same problem.

[andries]

I'm sure - first "println" of attached earlier function is running in expected time. Next line (fmpro.PerformScript) is blocking itself and the rest of lines. It's confirmed by attached Console messages.

Exactly. But this doesn't prove your point It is possible that by design the fmpro object is designed to not work in a multi thread environment (and that first the main thread has to liberate it before it can be used by another thread). If you use the Timer class, your function is registered to run in a background thread at the specified time. As you can see from your tests, it is triggered at the expected time, but the thread cannot use the fmpro object (or it blocks there anyway, that is the only fact in my assumption). This might be caused by the fact that the fmpro object is blocked by the main thread.

But as I said, this is just my impression, and some one else should verify/confirm this answer as I can be completely wrong here. I have seen that this fmpro object is working as expected as long as you use it in the main thread of your script. The moment you try to let it run on a different thread, you get this unreliable behavior.

Please be aware, I fully agree on the fact that the module "CallScriptWithDelay" is not functional or reliable. I am just trying to find out what is causing it.

[marek]

I'm not strong in Java and Groovy at all. Different threads is something I didn't think about. But are the "println" from my test the same thread as timer is? They are printing real times in Console - correct time of timer start and exact time of fmpro delay.

Anyway, thanks for your efforts to explain me what the reason can be.

Please let me know if you find solution.

[Smef]

I can confirm that this module is not currently functioning correctly. We may correct or remove this module in a future build of scriptmaster.

[andries]

Hi David

do you mean that we cannot use the fmpro object in different threads except the main one? Is this caused by FileMaker's plugin design, or the design of the bridge between Groovy and the FileMaker plugin API?

Andries

edit: using the fmpro object on a different thread works... so something else is going on (I know the code underneath does not really make any practical sense...)

SampleClass sc = new SampleClass()

sc.fmpro = fmpro

sc.scriptToRun = scriptName

sc.fileName = fileName



//Create thread

Thread t = new Thread(sc)

t.setPriority ( Thread.MAX_PRIORITY );

t.start()



return "running"







public class SampleClass implements Runnable {

	 def fmpro

	 def fileName

	 def scriptToRun



	 public SampleClass() {



	 }



	def void run() {

		  fmpro.performScript(fileName, scriptToRun)

	}

}

[dansmith65]

I haven't been on the forums much lately, so I haven't seen this thread until now.

I think this issue has something to do with thread priority. I put together some sample code for you to test; it seemed to work for me. The only important change is 'Thread.currentThread().setPriority(Thread.MAX_PRIORITY)'. If you use this to run a script which shows a custom dialog which displays both the current timestamp and the script parameter, you will be able to see the difference in scheduled trigger time vs. actual trigger time.

//calculate date/time script should be triggered

def dateformat = new java.text.SimpleDateFormat("dd/MM/yyyy hh:mm:ss")

def cal = Calendar.getInstance()

cal.add(Calendar.SECOND, Integer.valueOf( delaySeconds ))

def schStart = dateformat.format(cal.getTime())



def param = "Scheduled start: " + schStart



int delayMilliseconds = Integer.valueOf( delaySeconds ) * 1000;

def timer = new Timer()

def task = timer.runAfter(delayMilliseconds) {

	Thread.currentThread().setPriority(Thread.MAX_PRIORITY)

	param += "\n"+"Thread Priority: " + Thread.currentThread().getPriority().toString()

	fmpro.performScript(fileName,scriptToRun,param)

}

return schStart + "\nMain Thread priority: " + Thread.currentThread().getPriority().toString()

There is a short explanation of the valid values for thread priority here: http://dansmith65.gi...n.html#priority

(in the sample code in this comment, I used Thread.MAX_PRIORITY rather than an integer value, but it can be replaced with an integer from 1-10)

[marek]

Hi Dan,

I have not good news, we are on zero point back.

I made test as you suggested, but found it's not measuring real time of fmpro execution delay. So I aded Get(CurrentTimeStamp) to display of "param" in this dialog. Please find as attached 2 screen shots (one with dialog triggered by fmpro, and second with script).

Setting the priority of fmpro thread to MAX_PRIORITY is working - fmpro thread priority is 10, Main thread priority is 6.

But fmpro was only triggered as was expected after delaySeconds = 1 second (the same as in my example above). The time coded in "param" is correct and equal to time returned by SM function. But for execution I was waiting 118 more seconds. As you can see on attached screen shot it was somewhere blocked and executed after 118 seconds even if at maximum level of thread priority.

So in my opinion it's not problem of thread priority. By the way the same problem exists in oo_ScriptMaster's ScriptCron functions.

[dansmith65]

I wonder if it's a Mac-only issue. Both this and oo_ScriptMaster's ScriptCron functions work for me in Windows Vista and 7.

I don't think I can help on this anymore; as I don't own a Mac to test on.

[marek]

Hi Dan,

It seems not to be Mac problem only. I tested the same file on:

1. PC computer running Windows 7 Professional. Maybe unexpected delays are smaller, but also exist.
   With delaySeconds=1 real delay of fmpro run is 1 - 30 seconds.
   
2. Windows XP running on Parallels on Mac computer (the same computer having described above problems under Mac Os X) - seems to work exactly as it should, from time to time sporadicaly was 1 sec additional delay.