Ira, Finnian, Bill H, et al

[whanigsberg]

RE: Ira, Finnian, Bill H, et al

Hi Cal,

All well and good. I agree with everything you said (and do the same). But I wonder whether this practice has the inadvertent consequence of keeping commands synchronized.

Bill

[JohnZaleski]

RE: Ira, Finnian, Bill H, et al

Bill,
Lucky you, I haven't a clue where the hydrants are. One of the timing problems I had went away when I did exactly what you described (closing and reopening). It also went away when I placed a several second pause in the script. Almost anything I caused to happen at the point one process ended and just prior to another process starting caused the problem to go away. I have a feeling Selwyn might be interested in Martin's problem if it can be produced on demand.

[csda1]

RE: Ira, Finnian, Bill H, et al

Hi all,

I tend to use scripts very seldom preferring to call functions. If I do run a script, it is typically at the top most level and never invokes a script itself.

I suspect that each script is essentially opening it's own session and running to completion (more or less). If you made the scripts into a function (possibly with no parameters) and then said something like

script1()
script2()

I bet you they would run in succession. In fact, functions almost by nature must be synchronous, as they could return a value that might be used later.

I have seen an occasional syncing problem, but it has always been when running a spawned task (seldom used today) or when a sys_shell() is invoked.

Perhaps I am lucky or just use the right technique, or both.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[martinwcole]

RE: Ira, Finnian, Bill H, et al

yes - to Ira's point: they have to run successively if invoked as functions. and, on a form where the files referenced in the functions are also in the form, if i push a button [update balance due] and use functions, everything works great

the problem i am having with this is that the user "edits a charge" on another form. that form records the changes to that file/set, closes, and reopens the main form - i have been trying unsuccessfully to get those functions to fire at the onactivte event for the form or the onarrive event of an object by either calling them, or pushing the [updatebalancedue] button - to update the balance due. but if i do that everything freezes for a long time - sometimes comes through, sometimes says iot can't find the file or alpha can't find an alphabit ddd or something

but at least i have written two functions and aren't afraid of them anymore - and they do work better than script_play's

the only thing i haven't tried yet is at the onintialize event for the form - and am a fixin too

thank's for all the help to everyone

[JerryBrightbill]

RE: Ira, Finnian, Bill H, et al

Bill,
One area where opening and closing a table after each step seems almost a necessity is chaining operations. I normally include the operation code for append, post etc as low level code in a script. I found if I ran a couple in succession on a single table without closing and reopening after each step, I normally returned an error. Saving the operation and calling each in succession with operation.run worked ok. Adding a close and reopen has solved the problem in every case, at least so far.

Jerry

[whanigsberg]

RE: Ira, Finnian, Bill H, et al

I have learned to employ the same practice in such situations.

Bill

[whanigsberg]

RE: Ira, Finnian, Bill H, et al

Martin,

Perhaps I am lost in the details of this long exchange but what instead of 3 scripts in which the first calls the 2nd and 3rd in succession, what if you took the same code and pasted it together in one long script just to test if the problem is synchronization. Or did you already try this?

Bill

[Willard]

RE: Ira, Finnian, Bill H, et al

Martin, When Ira takes the time to respond you should study his comments extensively. His comments are short and to the point. As is with most of his responses he has the answer. It will take some effort to understand it but give it some time and reread it over and over again.
His solution will save you lots of problems.

[martinwcole]

RE: Ira, Finnian, Bill H, et al

Yes, Jack, I agree - when Ira responds, to include a few others as well, I sit up.

But I found the problem.

I noticed on the same troublesome form that when I pushed another button that deleted the record, when I used the functions, they worked like lightening, and perfectly, and i was able to put everything in order

- please note that since Selwyn said to put parentform.close() as the last line in any script, not leaving any commands to follow, I found that where I was having one computer crash and not another, that that was the problem!

on the save button, the first command was parentform.commit()

I moved the commit() command to the onarrive event for the button, and all of a sudden everything works perfectly -

....parentform.commit() ... moved to on arrive
cnum=parentform:cust_number.value
fixone(cnum)
uponebalance(cnum)
form.view("master form")
parentform.close()

this is my conclusion: (correct, maybe?!!)
when i say form.commit() and then call the functions, i think there is a time when alpha is updating the indexes for the set at the same time the functions are opening the files and manipulating them - thus one of the errors [can't find the file].

so, if I am correct, then it is a timing issue, but not one there wan't an easy fix for.

i also think that by putting the scripts in functions instead of script_play's, that that stopped timing issues between the two scripts

i need two functions as in some instances i call one, and in others i call both