Topic
  • 4 replies
  • Latest Post - ‏2014-02-26T19:06:24Z by llandale
Bob3
Bob3
9 Posts

Pinned topic readFile() nonfunctional with relative path

‏2014-02-21T21:07:08Z |

Has anyone else encountered the readFile() function not functioning when fed a path that is relative to the addins location?

It only seems to work if fed an absolute path. 

I suppose the workaround would be to manually read the file in using Streams. Any other ideas?

  • Mathias Mamsch
    Mathias Mamsch
    2003 Posts

    Re: readFile() nonfunctional with relative path

    ‏2014-02-22T12:25:42Z  

    Streams also don't work with relative paths as far as I know. Relative Paths only work with respect to the current directory, i.e. the directory from which the DOORS client was started from (or which is defined in the Windows Shortcut).

    The usual workaround is to search the environment manually querying the current Directory, Commandline Parameters, ADDINS Path, Project Addins Paths, etc. to have the same include order as DOORS has. You can find an example code in the Parallels Library:

    https://github.com/domoran/DXLParallels/blob/master/lib/core/System.inc

    Regards, Mathias

  • Bob3
    Bob3
    9 Posts

    Re: readFile() nonfunctional with relative path

    ‏2014-02-22T17:31:41Z  

    Streams also don't work with relative paths as far as I know. Relative Paths only work with respect to the current directory, i.e. the directory from which the DOORS client was started from (or which is defined in the Windows Shortcut).

    The usual workaround is to search the environment manually querying the current Directory, Commandline Parameters, ADDINS Path, Project Addins Paths, etc. to have the same include order as DOORS has. You can find an example code in the Parallels Library:

    https://github.com/domoran/DXLParallels/blob/master/lib/core/System.inc

    Regards, Mathias

    Thanks for your reply, Mathias!

    Not to be contradictory, but I was able to arrive at a solution that used my addins-relative path with Streams:

    Stream input
    
    Buffer b = create(20000)
    
    string includeFile = (string get(configFileData, 3, 0)) "\\BuildRE_Mod10.inc" //Builds a path relative to DXL addins root
    
    //If includeFile path is accessible by current user, proceed to read it in
    
    if (canOpenFile(includeFile, false)) {
    
        input = read(includeFile)
    
        input >> b
    
    } else { //includeFile path was inaccessible
    
        infoBox("Relative path to include file\n" includeFile "\nwas unable to be accessed. Please correct this DXL addins error and try again.")
    
    }
    

    It just seemed inconsistent for much of DXL to understand and cope with relative paths and then readFile() inexplicably does not. 

     
  • Mathias Mamsch
    Mathias Mamsch
    2003 Posts

    Re: readFile() nonfunctional with relative path

    ‏2014-02-22T20:20:38Z  
    • Bob3
    • ‏2014-02-22T17:31:41Z

    Thanks for your reply, Mathias!

    Not to be contradictory, but I was able to arrive at a solution that used my addins-relative path with Streams:

    <pre class="javascript dw" data-editor-lang="js" data-pbcklang="javascript" dir="ltr">Stream input Buffer b = create(20000) string includeFile = (string get(configFileData, 3, 0)) "\\BuildRE_Mod10.inc" //Builds a path relative to DXL addins root //If includeFile path is accessible by current user, proceed to read it in if (canOpenFile(includeFile, false)) { input = read(includeFile) input >> b } else { //includeFile path was inaccessible infoBox("Relative path to include file\n" includeFile "\nwas unable to be accessed. Please correct this DXL addins error and try again.") } </pre>

    It just seemed inconsistent for much of DXL to understand and cope with relative paths and then readFile() inexplicably does not. 

     

    You have every right to be contractictory ;-) I just tested it and realized Streams also read relative file paths ... Darn. Should have known that earlier ;-) Stat does not, therefore fileExists_ does not. Maybe I have never bothered with it just because it is so inconsistent ... I was certain that I already examined that because I have used that "workarounds" for years. Never mind then, regards, Mathias

  • llandale
    llandale
    3010 Posts

    Re: readFile() nonfunctional with relative path

    ‏2014-02-26T19:06:24Z  

    Streams also don't work with relative paths as far as I know. Relative Paths only work with respect to the current directory, i.e. the directory from which the DOORS client was started from (or which is defined in the Windows Shortcut).

    The usual workaround is to search the environment manually querying the current Directory, Commandline Parameters, ADDINS Path, Project Addins Paths, etc. to have the same include order as DOORS has. You can find an example code in the Parallels Library:

    https://github.com/domoran/DXLParallels/blob/master/lib/core/System.inc

    Regards, Mathias

    Here is an incomplete thought.  All my DXL use relative #include statements. "#include <Includes/NameIncludeFile.inc".  This presumes the "addins" variable points to the parent folder.  Some guy was using DOORS on Citrix and running the DXL was failing because"addins" variable was not set on the Citrix server.  However, being rather clever, he opened a Windows Explorer from the Client PC and navigated to the base "addins" folder; under which was the "Includes\" sub-folder; and then suddenly the DOORS client on Citrix was able to resolve the relative paths, even when it had failed only seconds before.

    I was surprised and shocked.  Did some experimenting and confirmed that Citrix was resolving vis-a-vis the "current Directory".  However, I was not able to duplicate this success for a DOORS client running locally on the PC.  I never bothered to reconcile whether the native relative "addins" in DOORS was relative to the "Current Directory" or the "Install Directory" (although now it seems is the Current Directory).

    What I wanted to do, but failed, was to allows a DOORS client running on a local PC to run DXL that set the "current Directory" and therefore find the DXL includes, rather than forcing that client to set it's "addins" variable ahead of time.  I wonder, is this an achievable objective?

    -Louie