I am trying to open a PDF file in a Web App and I cannot get this code (below) to work. Testing has shown It always ends up at the MsgBox(“Cannot open”) because the “f.Exists” fails but “f” is NOT nil. This is in DEBUG on OSX. I am POSITIVE the file exists and it will open if I double click the PDF via Finder.
I have tried the created directory that I want to use in my user account home directory and I have placed the file in the working directory where the program is running.
Does the standalone web server used for debugging not have permission to open the file? The permission is R/W for my account and Read Only for others.
Any insight would be appreciated.
Dim fname as string
Dim fpath as string
Dim MyFile as WebFile
Dim f as FolderItem
fname = ListBoxPDFlist.Cell(ListBoxPDFlist.ListIndex, 0)
fpath = FileListPathArray(ListBoxPDFlist.ListIndex)
f = GetFolderItem(fname)
if f <> Nil and f.Exists then
MyFile = WebFile.Open(f)
MyFile.ForceDownload = false
Also, your logic on f not being nil is incorrect. Your code above is testing for both f <> nil and f.exists. This in no way guarantees that f is NOT nil as you stipulated - you don’t know which condition results in the msgbox, it could be both!
That said, I agree that omission of the path component is the real problem.
Sorry … This is a bit misleading. My last iteration was to copy the file I wanted to open to the same directory as the working directory for the executable (debug directory) and remove the path from the code.
Jay I can see you are correct … but I copied the code from an example in the XOJO help and did not give it much thought. I did do some other testing (not shown in the sample code) to test separately for the NIL value of “f” and the “f.exists” and the value was NOT NIL when I was using the full path or only the current working directory without a path. So Tim’s comment would indicate that the path must be correct.
The “f.exists” always failed no matter where the file was located. I even did a copy/paste of the output from this message box, msgbox("("+fpath+fname+")"), to get the EXACT path used by the program and I am 100% sure the path and file name do point to the file.
I just learned that the “.debug” directory is removed and added back when you compile your project. My file was getting deleted. Not sure how I missed that other than being tired last night when I started this debugging. I really don’t want the file there anyway but I was trying to eliminate any issue of a path to another directory.
Wayne … thanks for sending me down that path (no pun intended).
SO … I copied the file back AFTER the compile and it now exists.
BUT … It appears to open a Webfile it must be a SESSION Property. I was getting a 404 error from a ShowURL until I made the Webfile a Session property.
AND … I still need to track down why I cannot open it in a different directory (not the .debug). Maybe it will just work now.
I quickly modified the Downloading example from Xojo by simply adding a folderItem and making ForceDownload = False.
dim f as FolderItem = specialfolder.desktop.child("shuttlelaunch.png")
App.LogoFile = WebFile.Open(f) // MyFile is a property on the App object
App.LogoFile.ForceDownload = False
If App.LogoFile <> Nil Then
MsgBox("The logo file is not available.")
This works perfectly, with a png.
But when I try to open a PDF instead, it simply does nothing. Am on a Mac and the same occurs with Safari and Chrome, both opening perfectly the same file if I drop it over. Something else must be going on.
[quote=108087:@Michel Bujardet]Continuing experiments with the PDF file, I think there is something definitely wrong with PDF files in Xojo web.
The very same code with ForceDownload = True perfectly downloads the PDF file.
So the file is indeed seen correctly by the app. RTF files do download file as well, and txt files are displayed by the browser if ForceDownload is not true.
Now, why does ShowURL appear as it is canceling viewing of the PDF file and not other types ?
I verified that the file uploaded on my server is displayed correctly by the browser when the URL to it is used.
It very much looks like a bug. Or is there some hidden setting somewhere that intently and specifically suppresses PDF display ? Greg ?[/quote]
It’s not a bug as far as I can tell. Usually the issue is in how the browser displays PDFs. For instance, if you have acrobat reader installed, you get a very different experience as when you don’t and you are relying on the browser to handle it without a plugin.
If I want the Webfile to be private to that session would I make it a session property?
If you want a WebFile to be private to a particular session, either create it while interacting with that session, or set the WebFile.Session property to the session you want it connected to.