Jump to content
Salesforce and other SMB Solutions are coming soon. ×

slow script results


Recommended Posts

I have a database that requires the user to click on a button to perform a script that enters data into another field. It works well, but slowly. There is a noticable delay between pushing the button and the information appearing--and it's not that complicated of a script. I believe I read somewhere about using container fields as buttons to run scripts to speed them up, but darned if I can figure it out! Can anyone help me out?

Link to comment
Share on other sites

afaik container fields as buttons don't have any effect on script speed.


for simple use, you can paste a graphic into a global container and then format this field as a button.


here's how I do it to make toggle buttons (that have the effect of looking pushed, or having switches or whatever):

-create a global repeating container field with as many repeats as you need different buttons

-create a global container field (non-repeating) for each script

-paste the graphics into the repeating field

-paste the graphic of your choice into the button container


in the scripts, use


set field["gButtonForScript", "GetRepetition(gButtonRepeater;repetition_number)"]


to toggle between graphics. When needed you can wrap it in an if-end if procedure.


As to script speed, the number of script steps is not the only relevant matter. if your script makes use of sorting, replace values, picking up related values, sum() or summary functions, then it may be slow, especially if you have a big file.




Link to comment
Share on other sites

Hi Kjoe and Copies,

FWIW I recently had a calc field that was based on the sum() function. On a layout that contained a portal and the calc field shown outside the portal it also took 5-6 seconds to do the calc(on very few,

Doing away with the display of the calc field and using a simple 'set field to sum()' and then displaying this field did away with the problem altogether.




Link to comment
Share on other sites

Thanks, kjoe & Inky Phil. Good information--and I'll put it to use, but for this problem I'm still struggling. Here's what I'm doing: I want to click on a button like I'm using a calculator. So if I click on the "1" button, a "1" should magically appear in the field my cursor is in. You can create my setup with 3 fields: Current, Tempchar, and Final Number. A button is set to run this script:

Set Field [tempchar, 1]

Set Field [final number, final number & tempchar]

Set Field [final number]


So with your cursor in Current, if you click on the button, the 1 pops into current. If you click it again, another 1 is added to become 11, and so on.


The problem is that if you click rapidly, say if you want to have 11111, you lose one or two of the clicks because the script is too slow.


Does anyone have any suggestions to speed it up?

Link to comment
Share on other sites

It is not clear why you need 3 fields, and 3 script steps. You could accomplish the same thing with one field, say final number and a single script step:


Set Field [final number, final number & 1]


With Set Field, it doesn't matter where the cursor is.



If you want to make this efficient, you can try:


Set Field [final number, final number & Substitute(Status(CurrentScriptName), "Set ", "")


Then duplicate your script several times and name each copy "Set X", where X is the character to insert. That way you only have to write the script once. By simply changing the duplicate script names, their action will change accordingly.

Link to comment
Share on other sites



I made a tester. Your problem (script skipping a beat or two) persists, even using Comment's one-line script .

No difference when using Insert Calculated Result[] instead of set field[ ]. It is, as you suspected, the button. Using a container as button makes no difference.


When you call the script from the menu bar in v6, there is no problem.

What you can do is make your ten scripts and keep them visible in the menu bar. So +1 would be under cmd-1, +2 under cmd-2 (mac menu, for win probably cntrl-1 etc?) until cmd-9 and cmd-0 .

then fast users could resort to the menu bar.


Curiously enough, version 7 reacts just as slow from the menu bar frown.gif




Link to comment
Share on other sites

  • 2 weeks later...

thanks again, kjoe. I do need the button, it's for a touch-screen monitor. But when I tried it in Version 7, it does seem a bit faster--not much, but anything's better than nothing at this point!

Comment: I like your 1-line solution, it's a lot cleaner than what I had, and I've replaced my scripts. Thanks!


Thanks, everyone for your help. If you come up with anything, I'll be looking!

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...

Important Information

Terms of Use