A non-persistent file?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • wolfgang.woegerer@gmail.com

    A non-persistent file?

    I have a pdf document saved (as a base64 encoded string) in a remote
    database. I now want to allow the client application to display that
    document. Because of legal issues I am not allowed to temporarily save
    the pdf document on the local hard disk.

    My question: Is there a way in C# and the .net framework to display
    the pdf document, say in the Acrobat Reader, without saving the pdf
    file to hard disk?

    At a first glance I would say no. The Acrobat Reader needs the path to
    a file name as an argument. And how could we tell the Acrobat Reader
    at what location in memory the file would start?!

    But on a second glance, maybe there is a part of the Windows operating
    system that has some kind of unique file name (or some kind of handle)
    and allows some kind of a data stream. Just an idea.

    Thanks in advance,
    Wolfgang
  • Ignacio Machin ( .NET/ C# MVP )

    #2
    Re: A non-persistent file?

    >
    At a first glance I would say no. The Acrobat Reader needs the path to
    a file name as an argument. And how could we tell the Acrobat Reader
    at what location in memory the file would start?!
    >
    But on a second glance, maybe there is a part of the Windows operating
    system that has some kind of unique file name (or some kind of handle)
    and allows some kind of a data stream. Just an idea.
    Somewhere in the back of my head I have the idea that windows support
    a kind of isolated storage , or something like that you could use to
    save the file into.

    Your problem though is the reader, if you find a component that
    display a pdf (I think there are some around) you could display it
    directly from your app and most probably without saving it to hdd.

    Comment

    • =?Utf-8?B?Q2lhcmFuIE8nJ0Rvbm5lbGw=?=

      #3
      Re: A non-persistent file?

      The .NET isolated storage is still saved on the FileSystem, it is put in the
      users profile area in Documents and Settings in the Application Data folder
      or somewhere like that. The only option for this would be to find a PDF
      viewer component that can open a PDF from a stream rather than from a file.
      You would need to check this with the authors and check that it doesnt save
      it to a temporary file to do it too.

      Let us know if you find one that does it as it would be good to know for the
      future.

      --
      Ciaran O'Donnell
      try{ Life(); } catch (TooDifficultException) { throw Toys(); }



      "Ignacio Machin ( .NET/ C# MVP )" wrote:

      At a first glance I would say no. The Acrobat Reader needs the path to
      a file name as an argument. And how could we tell the Acrobat Reader
      at what location in memory the file would start?!

      But on a second glance, maybe there is a part of the Windows operating
      system that has some kind of unique file name (or some kind of handle)
      and allows some kind of a data stream. Just an idea.
      >
      Somewhere in the back of my head I have the idea that windows support
      a kind of isolated storage , or something like that you could use to
      save the file into.
      >
      Your problem though is the reader, if you find a component that
      display a pdf (I think there are some around) you could display it
      directly from your app and most probably without saving it to hdd.
      >

      Comment

      • Chakravarthy

        #4
        Re: A non-persistent file?

        Wolfgang,

        First things first, it is not possible to stream the data to a PDF reader.

        Secondly, if you have to invoke the PDF reader, there has to be a file.
        thus, with out writing onto disk, you can't achieve this task.

        HTH

        <wolfgang.woege rer@gmail.comwr ote in message
        news:c4ad7bf1-390a-4618-93ea-5b45ce9fcbfc@56 g2000hsm.google groups.com...
        I have a pdf document saved (as a base64 encoded string) in a remote
        database. I now want to allow the client application to display that
        document. Because of legal issues I am not allowed to temporarily save
        the pdf document on the local hard disk.
        >
        My question: Is there a way in C# and the .net framework to display
        the pdf document, say in the Acrobat Reader, without saving the pdf
        file to hard disk?
        >
        At a first glance I would say no. The Acrobat Reader needs the path to
        a file name as an argument. And how could we tell the Acrobat Reader
        at what location in memory the file would start?!
        >
        But on a second glance, maybe there is a part of the Windows operating
        system that has some kind of unique file name (or some kind of handle)
        and allows some kind of a data stream. Just an idea.
        >
        Thanks in advance,
        Wolfgang

        Comment

        • Paul H

          #5
          Re: A non-persistent file?

          wolfgang.woeger er@gmail.com wrote:
          I have a pdf document saved (as a base64 encoded string) in a remote
          database. I now want to allow the client application to display that
          document. Because of legal issues I am not allowed to temporarily save
          the pdf document on the local hard disk.
          >
          My question: Is there a way in C# and the .net framework to display
          the pdf document, say in the Acrobat Reader, without saving the pdf
          file to hard disk?
          You could use some kind of RAM disk, but this requires installing drivers.

          --
          Paul

          Comment

          • Pavel Minaev

            #6
            Re: A non-persistent file?

            On Jul 10, 3:30 pm, "Chakravart hy" <dskch...@msn.c omwrote:
            Wolfgang,
            >
            First things first, it is not possible to stream the data to a PDF reader..
            >
            Secondly, if you have to invoke the PDF reader, there has to be a file.
            thus, with out writing onto disk, you can't achieve this task.
            This isn't quite correct - Windows allows to use named pipes in calls
            to CreateFile, so, as long as a program doesn't try to seek the
            stream, it should be able to read from / write to a named pipe. For
            example, you can use "type" to read from a pipe. Then, .NET
            application can use NamedPipeServer Stream to provide the data.

            I very much doubt it would work with any PDF reader, though.

            Comment

            • Peter Bromberg [C# MVP]

              #7
              Re: A non-persistent file?

              The only way I can think of is to have the source application send the
              stream via HTTP to say, a WebBrowser control in the client app with the
              correct Response.Conten tType. This would trigger the Acrobat Reader to come
              up and display the PDF in the browser window.
              Peter

              <wolfgang.woege rer@gmail.comwr ote in message
              news:c4ad7bf1-390a-4618-93ea-5b45ce9fcbfc@56 g2000hsm.google groups.com...
              >I have a pdf document saved (as a base64 encoded string) in a remote
              database. I now want to allow the client application to display that
              document. Because of legal issues I am not allowed to temporarily save
              the pdf document on the local hard disk.
              >
              My question: Is there a way in C# and the .net framework to display
              the pdf document, say in the Acrobat Reader, without saving the pdf
              file to hard disk?
              >
              At a first glance I would say no. The Acrobat Reader needs the path to
              a file name as an argument. And how could we tell the Acrobat Reader
              at what location in memory the file would start?!
              >
              But on a second glance, maybe there is a part of the Windows operating
              system that has some kind of unique file name (or some kind of handle)
              and allows some kind of a data stream. Just an idea.
              >
              Thanks in advance,
              Wolfgang

              Comment

              Working...