Working with PDF via VBA - overflow undetected

[is49460]

Hello,

I have some vba that loops through a dataset and populates pdf form. The form is saved as a separate file on every loop iteration. Overall, it suppose to create several thousands pdf's. The code never finishes executing. I get “run-time error '-2147417851 (80010105) Automation error”. After some research I figured out that JSO object uses some "stack" to store some “references” to the fields that are being populated. Can anyone suggest what do I have to do to reset that “stack” after every iteration for it not to overflow?

Thanks!!!

Here is a sample code that fails after about 8000 iterations on my PC:
(assuming there is a test.pdf with textbox named “test”)

Public Sub TESTPDF()
On Error GoTo test_error
Dim AcroApp As Acrobat.CAcroApp
Dim theForm As Acrobat.CAcroPDDoc
Dim jso As Object
Dim i As Integer

Set AcroApp = CreateObject("AcroExch.App")
Set theForm = CreateObject("AcroExch.PDDoc")
theForm.Open (C:\test.pdf)
Set jso = theForm.GetJSObject



For i = 0 To 30000
jso.getfield("test").Value = "abcd" 'that's the line that crashes eventually
Next i

Set jso = Nothing
Set rsAssetsSum = Nothing
theForm.Close
Set theForm = Nothing
AcroApp.Exit
Set AcroApp = Nothing

test_exit:
exit sub
test_error:
‘MsgBox Err.Description
End Sub
(I had to restart my PC to be able run the code again without getting run time error)

[ajetrumpet]

try putting something like this inside the loop:

if instr(cstr(j/5000), ".") = 0 then
   msgbox "Code stopped to prevent corruption.  Press OK to continue execution..."
      j = j + 1
else
   j = j + 1
end if

dim a long variable in the decs named 'j'. see if something like that helps the code run as planned.

you should never expect a computer and/or its memory capabilities to keep up with the speed of vba execution if the procedure has that many repeated tasks in it.

[is49460]

thanks for your suggestion.
If i run the code once till i get the run-time error, then i stop the execution and try to run the code over again, i get the run-time error on the first iteration. That leads me to thinking that timing is not an issue, but rather some stack gets full. any other suggestions?

try putting something like this inside the loop:

if instr(cstr(j/5000), ".") = 0 then
   msgbox "Code stopped to prevent corruption.  Press OK to continue execution..."
      j = j + 1
else
   j = j + 1
end if

dim a long variable in the decs named 'j'. see if something like that helps the code run as planned.

you should never expect a computer and/or its memory capabilities to keep up with the speed of vba execution if the procedure has that many repeated tasks in it.

[ajetrumpet]

what is JSO? you say JSO object. don't know what you mean, but the purpose of my suggestion was to help prevent memory stacks being compiled to fast. I think that's one of the reasons why vba loops forever if the code freezes the program.

I'm almost 100% that stacks are causing the problem, but when vba runs, in general, aren't memory stacks always an issue? vba still executes on machine-level after being compiled, right?

[is49460]

I called JSO object, the object that is set by GETJSObject call, that is referenced to pdf form (in my example it is called "jso").
i tried adding your suggested code to allow more time for excecution. Unfortunetaly I got the same results of run-time error.
would you happen to know how to reference the stack?

I see it being something like this:

For i = 0 To 30000
jso.getfield("test").Value = "abcd" 'that's the line that crashes eventually
'clear last item of the stack (?????)
Next i

But I have no idea what getfield() does besides obtaining field reference to the pdf, or how to reference the stack that is used by getfield().

The only remote reference to my issue i was able to find in Acrobat SDK was: "When working with a large number of documents, you must structure your code so that a new JSObject is acquired for each document, rather than creating a single JSObject to work on every document."
In my simple example i'm referencing the same field from the same document...
I have also tried to set jso = nothing after every iteration setting a new reference in the beginning of the loop, and again no luck.

Again thanks for your input!

what is JSO? you say JSO object. don't know what you mean, but the purpose of my suggestion was to help prevent memory stacks being compiled to fast. I think that's one of the reasons why vba loops forever if the code freezes the program.

I'm almost 100% that stacks are causing the problem, but when vba runs, in general, aren't memory stacks always an issue? vba still executes on machine-level after being compiled, right?

[ajetrumpet]

is,

I really doubt there is anyway to manipulate a stack of memory. Regardless of what program is running it and stacking the memory addresses (if that's what it's doing), that would be a high risk to MS because people would do it and sue the company for inoperable operating systems. so it makes sense really.

so you're doing this in vba, but with an adobe library? Again though, if you've gotten the code from somewhere else and didn't write it yourself, chances are you won't understand how to change it. I've been away from the forum, but did you say it crashes on loop 2? have you tried .close AND destruction of the object? for instance, for a recordset, the complete de-referencing procedure would be:

rs.close
set rs=nothing

have de-referenced and closed EVERYTHING that can be? the other thing is that you might be completely out of luck. you're getting 30,000 fields, and you can't close the form everytime.

I have no idea if that helps, but I think the article you read probably applies to any object in any OOP language, so it's nothing special...

and no, if there is a way to touch a stack of memory through top-level coding, I dont' know how. Again though, I doubt it's possible. I'm sorry, but i don't have experience with the PDF object in access, so my advice is pretty much at it's end here.

[is49460]

Adam,
Again thank you for you replies.
I agree that I most likely wouldn't be able to access memory stack directly. My thinking was there must be a way to get to it through methods offered by Acrobat (just like it gets filled up). And yes, I'm working with adobe library via vba. I have written all of the code myself and the loop with 30,000 iterations was just a very simplified example of what causes run time error. the first time I run the code it crashes after 8000+ iterations. Once I end the first excecution (after run time error) and try to run it again, it crashes on the very first iteration. I have to restart my PC to be able to run it again...
I did try to destruct jso object and declare it every loop iteration - no luck also...

is,

I really doubt there is anyway to manipulate a stack of memory. Regardless of what program is running it and stacking the memory addresses (if that's what it's doing), that would be a high risk to MS because people would do it and sue the company for inoperable operating systems. so it makes sense really.

so you're doing this in vba, but with an adobe library? Again though, if you've gotten the code from somewhere else and didn't write it yourself, chances are you won't understand how to change it. I've been away from the forum, but did you say it crashes on loop 2? have you tried .close AND destruction of the object? for instance, for a recordset, the complete de-referencing procedure would be:

rs.close
set rs=nothing

have de-referenced and closed EVERYTHING that can be? the other thing is that you might be completely out of luck. you're getting 30,000 fields, and you can't close the form everytime.

I have no idea if that helps, but I think the article you read probably applies to any object in any OOP language, so it's nothing special...

and no, if there is a way to touch a stack of memory through top-level coding, I dont' know how. Again though, I doubt it's possible. I'm sorry, but i don't have experience with the PDF object in access, so my advice is pretty much at it's end here.

[ajetrumpet]

is,

did you try my first suggestion? 8,000 iterations is WAY too long to go without a break. it is destined to crash for sure. did you enter a msgbox line after 5,000 like I initally said to do? that's not a perfect answer, but I know for a fact that it stops the crashing of the program, just like what you're experiencing.

and NO, I can tell you with 99% certainly that you can't access internal memory on a lower level than vba is on. And you can't do it through Adobe products either. The library is a DLL link only, it really has nothing to do with memory storage, addresses, or compilation and execution (directly speaking).

outside of the breakpoint after the spec'd intervals, I'm out of ideas.

But I can tell you that Adobe products are in a land of their own. If you rate the complexity and memory usage of their products to any others out there, the comparison is night and day, so I'm not at all surprised by the short time period for which your code crashes.

Take Dreamweaver or Flash. The installation is over 1GB size alone. MS Office 2010 ENTERPRISES doesn't even hit 1GB after installation, and there's how many products in that package?