Ira, Finnian, Bill H, et al

[martinwcole]

I will try tomorrow to write my first function. So far I have been using script_play("xxx") - but I am having this problem:

at the "save" button - i may say
parentform.commit()
script_play("scriptone") 'manipulate some files
script_play("scripttwo") ' read files and update the balance due
formview("nextform")
parentform.close()

but apparently things are not happening in that order, synchronously, and it is wreaking havoc.


if i put scriptone and scripttwo in functions, would things then occur in order?

currently the only way i can get things to work is to say:

parentform.commit()
parentform.close() 'THIS IS SUPPOSED TO BE ILLEGAL
script_play("scriptone") 'manipulate some files
formview("nextform")
---at the onactivate event of "nextform", check for a globalvariable, and if true
---script_play("scripttwo") ' read files and update the balance due

[Tom Cone Jr]

RE: Ira, Finnian, Bill H, et al

I, too, am interested in this topic - having encountered difficulities which seem to be related to the sequence in which scripts run. Are there any design guidelines available on this?

It seems that code which simply manipulates memory or opens and closes forms runs consecutively, one statement at a time. However, if the script includes code which manipulates tables (and by necessity their indexes), later statements in the script often seem to execute before the table processing is completed.

What's the best way to assure that the table processing has been finished, before the next code sequence in the script begins?

[Stan Mathews]

RE: Ira, Finnian, Bill H, et al

Tom,

From Bill in an earlier post.

"One approach would be to test for exclusive access before running your operation. If the test fails (meaning the table is in use by another process) you could put a timer delay on your process and have it try again. Perhaps give it 3 tries before it aborts."

Stan

[martinwcole]

RE: Ira, Finnian, Bill H, et al

like have a global variable "busy" - L
scriptone sets busy to true at start and false at end
scripttwo has if .not. busy ... else loop x times
etc.

??

[Peter.Greulich]

RE: Ira, Finnian, Bill H, et al

>>It seems that code which simply manipulates memory or opens and closes forms runs consecutively, one statement at a time. However, if the script includes code which manipulates tables (and by necessity their indexes), later statements in the script often seem to execute before the table processing is completed.

[martinwcole]

RE: Ira, Finnian, Bill H, et al

i am having various degress of success by the following:

var->cnum (customer number) is my application wide linking field, and most of my scripts, operations, etc. are based just on the var->cnum

i have made two functions
fixone as L(cnmbr as n)
this follows Peter Wayne's statement that a function must return something

so i say fixone(var->cnum)
then, virtually the same code in my script is in the body of the function
then i have another called uponebalance
in some situations i can say
fixone(cnum)
uponebalance(cnum)
and they seem to fire synchronously - not interfering with each other - but in other places the form freezes - further research underway

but i wish one of the top dogs would advise as regards this

[Stan Mathews]

RE: Ira, Finnian, Bill H, et al

Multithreading.

[Stan Mathews]

RE: Ira, Finnian, Bill H, et al

But not intelligent multithreading as I see it, especially when you can zap a table and have a command to append to the same table and the append will begin before the zap is finished.

[Finian Lennon]

RE: Ira, Finnian, Bill H, et al

Hi Martin:

I'd like to be able to offer some sage advice but, in the present circumstances, I'm too swamped to address the question much more than the following:

In general the functions I use are pretty straightforward either to return a value or produce a pick list and, strictly speaking that's just as well done with a script_play.

I've never had to use successive script_play commands (though I do frequently use conditional script_play commands) to get something to run, so I've not had the syncronicity problem you refer to, at least not since V1.

Finian

[CALocklin]

RE: Ira, Finnian, Bill H, et al

OK, you've got me curious.

I have a number of scripts that do things like this. One of them creates a new table (or copies to a new table?), sets up two relationships (child and grand-child), copies to another new table, posts some data from another table, then appends the result to the table that contains the desired report format.

I have never had any problem with this script or other similar ones that I use. All these scripts are either individual scripts on a button or, in most cases, the button will simply have a 'script_play()' command which activates a single global script. (I prefer to use global scripts because I can save development time by leaving the form open while editing scripts.) All my copy, post, append, etc. routines are also coded in Xbasic; I do not call saved routines.

My question is: Are people seeing this problem when everything is in one Xbasic script or is this something that happens when one script calls 2 or more 'script_play' commands within it. Or, is it perhaps when using in-line Xbasic in action scripts or when calling saved routines?

[JohnZaleski]

RE: Ira, Finnian, Bill H, et al

Martin,
This may not relate to what you are doing, but one of the things I do a lot of is run chains of scripts. A button on a form runs "scripta", and "scripta" runs "scriptb". I have had timing issues in other areas, but never with chaining scripts together.

Did you try putting a one or 2 second pause between the two scripts that you were originally trying to run back to back?

Good luck,
John

[Stan Mathews]

RE: Ira, Finnian, Bill H, et al

Cal,

My problem arises when using an inline xbasic "step" to run a script which contains multiple commands. If the table being manipulated is large enough, and you first want to empty the table, then append to it, the append will begin before the zap is finished.

Be glad to provide more detail and code if you desire.

Stan

[CALocklin]

RE: Ira, Finnian, Bill H, et al

Thanks, that's what I wanted to know.

You might be interested to know that I missed a step in me previous description. Before I append the data to the report table, if first Zap it. So, my guess is that everything would run fine if you convert the whole thing to one Xbasic script. I can't guarantee this because the way I build the tables the only data in the report table is the data used for the previous report - it isn't huge but I just ran it with 13,000 records and had no trouble.

Cal

[whanigsberg]

RE: Ira, Finnian, Bill H, et al

I'm flattered but I am no top dog even though I am starting to know where to find some of the hydrants.

Anyway, here is something to try. What if we were to:

open the table (rw_exclusive)
zap the table
Close the table

reopen the table
do whatever else we need to do
close the table

I *hope* that the close wouldn't execute before the zap is complete and the reopen wouldn't happen until the close had executed.

I have some recollection of seeing code organized in this fashion and wondering why someone would want to close a table only to reopen it. Perhaps this is the reason.

I'd be real interested in peoples' experiences.

Bill

[CALocklin]

RE: Ira, Finnian, Bill H, et al

Bill,

I can't tell you what effect it would have but I can tell you why I sometimes close a table just to re-open it a few lines later.

1. I wasn't thinking far enough ahead when I closed it the first time.
2. It is good practice to always close files and tables before ending a script and I find it easier to open and close them at each step. (ie, open the file, copy the data, close the file.) Usually there will be a few lines with something like a message box, traceln, hourglass_cursor, etc., ... or, at the very least, some comment lines telling what's happening between each step. These act as a good divider between 'steps' when I review the script for Open()/Close() combinations at a later date. Yes, theoretically it takes a bit more time for the script to run but it's insignificant compared to the amount of time it takes to run something like a copy routine. Also, it's insignificant compared to the time I waste trying to figure out where I opened each file and whether or not it has been closed. This also makes it easier if I change the script to either delete one of the steps or add something else in between.

The bottom line, I do it for my convenience; not to make the program run better.

Of course, that's only my opinion. Maybe someone else has found another reason. Anyone...?