Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
4 replies Latest Post - ‏2014-02-26T19:06:24Z by llandale
Bob3
Bob3
6 Posts
ACCEPTED ANSWER

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
    1954 Posts
    ACCEPTED ANSWER

    Re: readFile() nonfunctional with relative path

    ‏2014-02-22T12:25:42Z  in response to Bob3

    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
      6 Posts
      ACCEPTED ANSWER

      Re: readFile() nonfunctional with relative path

      ‏2014-02-22T17:31:41Z  in response to Mathias Mamsch

      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
        1954 Posts
        ACCEPTED ANSWER

        Re: readFile() nonfunctional with relative path

        ‏2014-02-22T20:20:38Z  in response to Bob3

        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
      2943 Posts
      ACCEPTED ANSWER

      Re: readFile() nonfunctional with relative path

      ‏2014-02-26T19:06:24Z  in response to Mathias Mamsch

      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