I have a print driver that creates adobe PDF files – when called, it lets you select the drive/path and name (in what looks like an old windows mode selector, not a new pretty one such as the PDF converter in OIPI). After this is run with the output directed to another drive or another directory on the current drive other than the default, RTP27 "freaks" out - I get errors about events not found, the debugger sometimes won't load and the app and OI developer will not close (picking anything on any menu, clicking anything, closing, etc just results in the debugger). At one point, I even managed to get a message that the application itself could not be located (despite it still running). In addition, there are graphics printed on these forms (all OIPI) that are loaded via relative paths – if printed into the current (OI) directory, they lock fine, but if using the adobe driver to another directory, I get blocks instead that must represent where graphic should exist. It looks like OI is forgetting where it "lives" after this driver changes directories.

I was trying to avoid wasting paper during testing - the process being run (printing checks) does not allow preview, in an attempt to prevent people from storing copies ready to print (not foolproof) and only allows picking a printer and then printing. Although, of course, I could stop using this driver, if a user were to have the same type of driver (or another that changes directories), they would have the same problem.

To test, I've now run this many times and can consistently crash OI just by selecting a directory in the printer setup. Doing so when checks are printing (since Set_Printer("INIT",…) is calling the print setup) will crash it, as will changing my printer to this driver and then selecting "print" in the viewer (for any report) and saving the PDF into another directory. Printing to real printers or saving in the current directory or using the built in OIPI Save to PDF (to any location) all work with no errors.

So – (a) any ideas on what is being broken? (b) is there any way to try to "force" the defautl OI directory back to whatever the default is? I suspect that doing this after calling set_printer might be enough to solve this, at least for direct printing (any fixes to the problem that occurs inside the OIPI viewer would be RTI required, I would think - it would be needed after printing, just in case the directory/context has changed).

We used to see this back with Win 3.1 and OS/2, where the driver being called would swap the current dir out from underneath. Some drivers allowed for an option, or a run in location, but most didn't. To prove this, see if you can move the driver into REVBOOT. You might have to reinstall or make registry modifications.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I'll give that a try, but suspect the driver along isn't the problem – if I let it save the PDF file in the current OI directory, which is always the default, then there are no problems at all. Of course, even if it is the problem, it will be an issue that customer will run into and drive us crazy trying to fix.

Can anyone refresh my memory on which property sets OI's current directory, so I could just "fix" it where I am seeing it occur?

Hi Karen

I cannot remember of a native oi function to do a chdir.

You can use windows scripting host as ole object, or implement the setCurrentDirectory function in the windows API.

An example of setCurrentDirectory appears below.

You would use it as

hold_dir=Drive()

Call MyIllBehavedFunction()

call Chdir(hold_Dir)

HTH

Bob

pre.code {

 background-color: #E5E5E5;

 border: 1px solid #000000;

 width: 640px;

 padding: 5px;

 font-family: courier, verdana, arial, serif;

 margin: 0px 10px auto;

}

function ChDir(path)

/*
**  Use SetCurrentDirectory to change current directory
**  NewDir (in)= New Directory.
**
** 09-11-06    rjc    translated from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/setcurrentdirectory.asp
**
*/

declare function SetCurrentDirectoryA, RowExists

$insert Logical

If Assigned(path) Else path='
If NewDir # '' then
   path_exists=( dir(path) # '' )
end Else
   path_exists=false$
End

if path_exists else
   call Set_Status(1, 'Invalid Directory')
   return ''
end

if rowExists('SYSOBJ','$SETCURRENTDIRECTORYA') else
   GoSub Create_Prototype
end

success=SetCurrentDirectoryA(path)
if success else
   call Set_Status(1, 'Invalid Directory')
end

return ''


Create_Prototype:

/*
* Prototype WinApi Calls
*/

// Ansi version, from VB WinApi Declarations
// Public Declare Function SetCurrentDirectory Lib "kernel32" Alias "SetCurrentDirectoryA" (ByVal lpPathName As String) As Long


lib=KERNEL32'
prototypes=LONG STDCALL SetCurrentDirectoryA(LPASTR)'
proto_id=DLL_':lib
proto_rec=Xlate('SYSPROCS', proto_id, '', 'X')
orig=proto_rec
if proto_Rec=' then
   proto_rec=lib
End

col='
loop
   remove prototype from prototypes at col setting flag
   if prototype then
      exists=indexc(proto_rec, prototype1,'(', 1)
      If exists else
          proto_rec=prototype        
      End
   end
while flag
repeat
if proto_rec # orig then
   call write_Row('SYSPROCS', proto_id, proto_rec, 1)
   call declare_fcns(proto_id)
end


return
   

Bob, that worked (more or less). The "ill behaved function", by the way is this one: Set_Printer( "INIT" ) if the output is direct to the printer and the printer driver changes the directory (seems like perhaps set_printer might want to check that and correct, as I'm sure I'm not the only one who has run into this … and one fix would fix everyone, rather than the hundreds fixing the thousands of occurances of calling set_printer).

DefDir='

GetCurrentDir( '', DefDir )

Status=Set_Printer("INIT", tViewerTitle, title, margin, Orientation, ViewerMode)

NewDir='

GetCurrentDir( '', NewDir )

if NewDir # DefDir then

	SetCurrentDir(DefDir)

end

Anyway, the SetCurrentDir (named to match the already present function that finds current dir) function does work – but ONLY if you either run it when there isn't a problem first or create the prototype yourself (which is what I did). Once the default directory has been shifted, it cannot read any records to update the SYSOBJ and SYSPROCS records. Therefore, it crashes just like everything else in OI was doing. Once the prototype exists, however, it gets called just fine and resets the directory back so that OI functions again (so long, of course, as it is called just after the ill-behaved function and before OI attempts much other disk access).

View this thread on the Works forum...