xbasic curiousity "ax_choice etc"

[JohnZaleski]

The script below runs perfectly as converted or unconverted in line basic. I can run it as many times as I want and it will open the selected file with acrobat. When I strip out Alpha's "ax" error trapping the program will run the first time. If I run it again it will produce a fatal error. The fatal error appears immediately upon running the program. This happens every time.

alpha error
ALPHA5 caused an invalid page fault in
module MSVCRT40.DLL at 015f:1021d7f3.

it's running fine but I was wondering what's going on with Alpha's "ax" code.
DIM ax_choice as C
DIM ax_response as N
DIM ax_dialog as P
and all the rest

I was under the impression that it was basically for error trapping, but the situation I just described sounds like there's more to it than that. I repeat it's not a problem but if somebody knows the answer I am very curious.

DIM file_names[250] AS C
old_directory = dir_get()
dirname = "c:alphadoc11025"
dir_put(dirname)
'***populate the array
files = filefind.first("*.pdf")
I = 1
WHILE .not. files.eof()
file_names[I] = files.name()
files.next()
I = I + 1
END WHILE
'***allow user to choose and cleanup
dir_put(old_directory)
sort_array("file_names")
result = ui_get_list_array("Select ",1,"file_names")
if alltrim(result) = "" then
goto alldone
end if
delete file_names
delete files
'*** read the selected file with Acrobat
progname = "C:Program FilesAdobeAcrobat 4.0ReaderAcroRd32.exe "
dirname = dirname + chr(92)
filename = alltrim(result)
command = progname + dirname + filename
sys_shell(command,3)
alldone:
end

[Tom Cone Jr]

RE: xbasic curiousity

I'm not sure what was in the code you deleted. I've always made the same assumptions about it's function as you mention.


In your code for this script you may want to use Redim() instead of dim() when declaring an array, especially if the script may be run more than once in the same session.


-- tom

[JohnZaleski]

RE: xbasic curiousity

Tom,
I used the "delete" variable command which removes the variable from memory before exiting. If you enter in line basic code ("action scripting") you have my program. If you do the "convert to zbasic" Alpha will insert error trappping code surrounding your in line script. Until I removed Alpha's "ax" code I had thought that the only difference in running a program without it was error trapping. I'm a little confused by the results.

[Tom Cone Jr]

RE: xbasic curiousity

Me, too.

-- tom

[Ohlen Cartmell]

RE: xbasic curiousity

As I recall, you can the error trapping is a selectable option when preparing an action script. Why not redo the script without the error trapping option selected and see how the script changes?

[JohnZaleski]

RE: xbasic curiousity

Tom,

Two things stopped the program from bombing:
1) As you suggested, I used the redim on tha array and the problem went away. I'll never not use a redim on an array again thanks to you.
or
2) As long as I put a dim statment in front of the first original "DIM file_names[250] AS C" statment it stopped bombing. When an inline xbasic program runs, this code is executed by Alpha before the code we write:
DIM ax_choice as C
DIM ax_response as N
DIM ax_dialog as P
and more

Using the redim or not having the array statemnet as the first reference to a variable both produce the same results.
Thanks for your ideas on this. My curiousity is satisfied. It seems there is a minor bug in Alpha's handling and clearing of arrays.

[JerryBrightbill]

RE: xbasic curiousity

John,
I find your problem puzzling. I cut and pasted your code onto a button both as inline xbasic and as straight xbasic without error trapping and see no difference in operation. I changed the directories to match paths on my computer and can click the button repeatedly without any errors developing. (Although Acrobat won't open the selected file). I even left Acrobat open and clicked again and again without problem. Your use of the dim array command should work fine as is.

I have seen the error you indicated, but it was the result of a memory problem with a video driver and had no connection to any script commands.

Incidentally, I like to use my own error trapping since the code generated by inline basic doesn't give a lot of information. Also, there is a limitation of the number of script lines in inline xbasic, so while I may create a script in using action scripting, I nearly always convert the code to xbasic and have never had a problem stripping the original error trapping code.

Sample error trapping code:

on error goto error_handler

'/// script body
end

error_handler:
msg = error_text_get(error_code_get())+chr(10)+chr(13)+"Error occured at line "+str(error_line_number_get(),4,0)
ui_msg_box("Error",msg,UI_INFORMATION_SYMBOL)
end

This code will give both the line the error occured and the complete error message.

Jerry

[JohnZaleski]

RE: xbasic curiousity

Jerry,

Thanks Jerry.

As Tom Cone suggested there are some problems dimensioning arrays which seem to be completed fixed by using the "redim" instead of the "dim". I'm not sure why you did not get it, but my problem was reproducable 100% of the time without it and completely went away once I used the "redim"
In this case it had nothing to do with anything other than the script itself.

Your problem with it not finding or opening the file in acrobat could be that you had spaces in the file name or the directory that the file resides in. The code I showed worrked if the file name or directory did not have any spaces. I changed the code a little to add quotes embedded in the final command line and that problem went away. If you create a shortcut on your desktop using the acrobat command with a target file, the quotes are necessary when there are spaces.

[JerryBrightbill]

RE: xbasic curiousity

John,
A little work with quotes solved the opening problem, but a thought came to me using arrays. Normally if the array is used only in a single script and designated by a simple dim statement, I have found no need to use redim. Normally, redim is used if the array is already defined and the size or type of the array changes. If the variable name is defined elsewhere as shared or global, then redim may be needed. I also had fun one time when I tried to use a variable name for an array that was already defined as a simple session variable on the calling form.

Check that the variable name isn't defined somewhere else. That may generate an error but still allow the script to run. Of course if redim works, why change

Jerry

[JohnZaleski]

RE: xbasic curiousity

Jerry,
It's not used elsewhere. Remember, the program worked perfectly the frist time. Once completed. with nothing running in between, it bombed the second time.The dim statement was the very first statement of my script. If I put a line in front of it's, let's say, part = "kk", the script no longer bombed. I have no doubt that there is a small "bug" in Alpha having to do with array variables that is most easily remedied by using redims rather than dims or being carful never to have the dim array statement be the first reference in a script to a variable. Tom Cone pointed out some "inconsistencies" with arrays that were completely cleared up for him by using the redims. "Inconsistencies" are the worst kind of errors to get because they are so difficult to trap. I vote for following Tom's advice.

John

[JerryBrightbill]

RE: xbasic curiousity

John
Weird behavior. The fact that the behavior is unexpected suggests that something is still not quite right, especially since the script runs fine the first time. For some reason, the program is not clearing the array reference. Using redim is good practice as long as it isn't just hiding some other condition. When I tested your posted script both as a standalone and as a button script, the dim statement was the first line. Both methods worked repeatedly until I had more than 10 files opened in Acrobat.

One possibility is some form of corruption in your data dictionary. At some point in your development did you try a dim shared statement? Even if it was deleted, a corrupted dictionary may still reference it. The fact that adding a line before the dim statement corrected the problem is strong evidence that corruption may be a present. The data dictionary is just a table itself and deleting a script just marks it for deletion, in the same way a table record is marked. Compacting the dictionary is supposed to remove anything marked just like pack works in a table, but sometimes it fails. Then when you to reference a script, the table may actually try to run the script code you think you deleted.

I have had this problem in the past when behavior was unexpected and I thought the problem was with the A5 program. Even compacting the data dictionary repeatedly did not solve the problem. Copying the table to a new name didn't help. The only solution was to recreate the table with a new name, recreate all forms, (if you copy a form from a corrupted dictionary, the problem may follow), and that corrected the problem. Since that is a LOT of work, I now regularly compact the database during any design changes. Since then, no unexpected behavior (other than developer mistakes).

One check would be to create a new script in the code editor and enter the code and run it as a standalone. Do not open any forms when you start the database, just try the script first. Your original message suggests you are running the script from a button. If the table data dictionary is corrupted, that should not affect a standalone script. You could also remove the button entirely, compact the database, and then recreate the button. That may work. I have even created a new database with no tables and only one script when I was especially paranoid about possible script conflicts with other events.

I am certainly not disaggreeing with Tom that using redim is good practice. When I first started using xbasic I didn't even bother with dim statements, I just set a value for a variable. Found that it doesn't always work correctly. Now I am more careful.

Jerry

[Peter.Wayne]

RE: xbasic curiousity

for what it's worth, i also was unable to reproduce your problem. your script worked repeatedly for me.

[JohnZaleski]

RE: xbasic curiousity

Peter and Jerry,
I created a brand new app. One test file nothing in it.
I made three scripts two that work and one that bombs. They are named appropriately. It's zipped and attatched. All you have to do is create the same directory, put a pdf file in it and run the scripts.

[JohnZaleski]

RE: xbasic curiousity

Once again it's the second time the program is run that it bombs, not the first.

John

[JohnZaleski]

RE: xbasic curiousity

Jerry,

I forgot to thank you for your last thoughtful message on the general subject. Give my attatched zip file a shot. I did make a brand new app out of it, but copied and pasted the script from the original. Exact same behavior. Since I got it working with the redim I was losing interest in the situation, but you've got me curious again. My client is using pdf's for archiving a number of things that fall into diffefrent categories. It wasn't until I removed the code from some in line buttons and created a global script that I saw the problem. I'm looking forward to a5v5 because it will add to the seamlessness of using pdf's for document imaging. Thanks again for your thoughts.

John