I am running an automated process in OI Version 8.0.8. It creates PDF's that are ultimately faxed and emailed. From time to time I get a message that stops the process. I am trying to write an error trapping routine. But this error message stops everything. It is:

"Not able to write PDF file"

Does anyone know how to either do away with the message or make it a timed message. Needing to know how to get a hold of the message.

Thanks

Jeff Miller

Miller's Software Services

This is somewhere where your best bet Is to shell MSG. Just check for that text, log it to a file so you know what failed then return without calling $RTI_MSG.

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

thanks Andrew for the reply,

I am not sure how to use RTI_MSG to find the message number. I am not really sure this is a message that I can control.

I am using OIPI to create a PDF. Every once in a while the routine cannot create the PDF. This OI displays the PDF error message. It puts a stop to the routine that requires me to click on the OK button on the error message. It appears that the windows server has issues from time to time. Nothing wrong with the data or OI. It looks like Adobe just quits. You click ok on the error message and all is good for another few days.

Any thoughts on how to keep this error message from staying up. Or even come up.

Jeff Miller

Miller's Software Services

Hi Jeff,

Copy the RTI version of the Msg object code to another name such as RTI_MSG. i.e.

 Copy SYSOBJ $MSG to SYSOBJ $RTI_MSG

Then create a function called Msg that takes the same arguments as the original Msg() function. In your new Msg() check the arguments to look out for the message that you want to ignore, and if you find it then just return null, otherwise you pass the arguments onto the original Msg() function that you renamed to RTI_Msg().

e.g. (Not Tested!!!)

function Msg( Window, MsgRec, MsgKey, Instruction, argv)



   declare function rti_Msg(), get_property

   $insert logical



   if assigned( window ) else window = ""

   if assigned( msgRec ) else msgRec = ""

   if assigned( instruction ) else instruction = ""



   bForward = TRUE$



   if ( instruction == "" ) or ( instruction == 1 ) then

      // It's an execute call - check for the message

      goSub filterMsg

   end

   

   if bForward then

      //  call the "real" version of Msg() 

      return rti_Msg( Window, MsgRec, MsgKey, Instruction, argv )

   end



return ""



filterMsg:



   // Look for the text of the message you want to kill... it could be in "window" if it's 

   // like an Arev Msg call, or in MsgRec if it's done like an OI call



  filterText = "Not able to write PDF file"



   if Get_property( window, "HANDLE" ) then

      // Look in MsgRec

      if index( msgRec, filterText, 1 ) then

         bForward = FALSE$

      end

   end else

      // Look in Window

       if index( window, filterText, 1 ) then

         bForward = FALSE$

      end

   end 

return

(Also - You will need to remove MSG from the SYSPROCNAMES record in SYSENV and restart OI before you can compile your own copy of Msg)

Carl Pates

Jeff,

My suggestion is to use Carl's code as a base but save it under a different name (e.g., MSG_HOOK) and then create a P-pointer to redirect the MSG function to your code using the steps outlined in the Hooking in BASIC+ - Using Different Bait blog. The advantage is that you don't have to touch the original $MSG object code and you don't have to worry about upgrades or patches restoring $MSG to the original version.

Don Bakke

SRP Computer Solutions, Inc.

My experience is that the pdf is actually created in the Users\%username%\AppData\ and some lower folder. At the conclusion of the pdf creation it is copied to the requested destination folder as the filename. Sometimes this fails and I believe this "Unable to create the file" is a Windows message, not OI.

Dave

Hi Dave,

Looking at the old code-base it's an actual OI Msg() that's called using the Arev style:

i.e.

   call Msg( someText )

This is why I suggested shelling Msg() as there's no SYSREPOSMESSAGES entity to trap (and 8.0.8 is extremely unlikely to get any updates! :) )

Cheers

Carl Pates

I see, thanks.

Now, why would it be unable to write to a folder, especially one that it had just written to successfully? That is what I experience infrequently.

Dave

Dave,

That is my issue. It works most of the time. I send through this program around 600 to 700 documents. It works most everyday. I just stops every 4 to 5 days. It stops throwing up this message that you need to click on to continue. Being an automated process that runs on its own causes a problem. Would like to do away with the message and test if the PDF was written and react from that point.

Jeff Miller

Miller's Software Services

View this thread on the Works forum...