For an intranet project, I need to open a certain folder for the convenience of the customer from within a Web App 2. How can I achieve that, with all the sandboxing? The shell doesn’t help, as the Xojo Web Server is on a different machine. This Javascript is working, when opened in the browser via an html.file, but I can get Xojo Web 2 to open such a file under “Resources”.
<script type="text/javascript">
function CallMe() {
window.open("file://H:/\PIBs und KIIDs/VIB/");
}
window.onload = CallMe;
</script>
I put that script into a HTML folder under Resources, but it seems that I cannot open it, with session.gotourl with whatever I’m trying. But I probably just tried too much, and I’m blind now.
Loading the HTML via textinputstream works, but the WebHTMLViewer is not executing the Javascript with LoadHTML(myInput).
It is probably something very simple, but I am just lost right now 
It doesn’t need to necessarily be my approach as a solution path. Perhaps it helps to explain the issue:
For some processes, my customer has different folders with tons of files inside for guidance. One challenge of the Intranet would be to point the user to the specific folder he needs. These folders should then just appear either in a new(!) browser tab or by opening the file explorer on Windows, Sounds like a very easy “concept” … but I just don’t get how to achieve it. Thank you for any hint.
I have some bad news for you.
This is impossible, as it is a security risk to let website code set any value on the machine.
https://stackoverflow.com/a/17420736/6047977
1 Like
Well the above Javascript is working perfectly fine when put into an html file and opening that, via the browser. I know about the sandboxing challenges. All I need is to find a way to mimic double-clicking on that html file. Popup warning and unsafe script warnings etc are not an issue, as on the intranet, I can handle those via GPO.
I still don’t think it’s possible with the current public browsers. Is a custom Xojo HTMLViewer desktop app a solution? You could implement JavascriptRequest and pop open an OpenDialog when you receive your own special flag.
1 Like
Yes, you are probably right, as below code is working, but not executing the JS script. It seems that a browser is doing the gentle difference if a user is actively(!) opening an HTML file, or a running “app” loading that same HTML file 
- I really hate this sandboxing stuff.
Var htmlData as string
Var htmlPath As FolderItem = SpecialFolder.Resources.child("html").child("vib.html")
If htmlPath <> Nil And htmlPath.Exists Then
Var t As TextInputStream
Try
t = TextInputStream.Open( htmlPath )
t.Encoding = Encodings.UTF8
htmlData = t.ReadAll
Catch e As IOException
MessageBox("Error accessing the HTML-file")
End Try
t.Close
end if
htmlFile = new webfile
htmlFile.MIMEType = "text/html"
htmlFile.ForceDownload = false
htmlFile.Data = htmlData
session.GoToURL(htmlFile.URL, true)
Plan B: reading all the files into a listbox … the important ones are pdfs … –
Plan C: Giving the user an upload dialog. At least the can then see the files 
+1 with a desktop version. A page initiated using the file: protocol could navigate the file system, but one initiate by other protocols, like http, will be isolated.
1 Like
Nope, they want to get rid of desktop apps, where every they can. But excellent idea, I like it.
They mainly are only dealing with files on their own servers. They are in a regulated market and need, for legal reasons (welcome to Germany) spam their customers with all kind of documents. So this is only to point them to the right documents needed to be pasted into their emails.
The biggest challenge is anyways to explain a happy customer so far, that what worked in their old intranet (designed with Frontpage or whatever that was called 2 decades ago) won’t work right now any longer ).
Security evolution closing exploiting surfaces over the time.
1 Like
Yeah, on the web it is absolutely the right thing to do, even for an intranet. Though there is a difference (for me) between just opening Explorer Files and actually executing files.
If that’s the case, what about a custom WebSDK control that could use this Javascript as the direct result of a user action rather than a round trip?
1 Like
Yes, good idea. Have to dig into the WebSDK then
FWIW, the browser will probably remember the last location you opened files from so they may only need to select the folder once.
1 Like
I found an easy way around the problem for an Intranet solution. I set up a separate web server listening on a different port and doing nothing but showing the folder with their data. Via Xojo I’m calling the respective subfolder etc. via
session.GoToURL( "http://localhost:8000/subfolder/")
They won’t like it the first time they are trying to drag&drop a file into an email, but I can implement that in Xojo, just give me the $$$ .
1 Like
I don’t get it. Having contents from a server never was a problem. I understood your problem as “I need the browser to open a local folder”
Xojo can’t show the content of a folder. Another local webserver can. Just using a local webserver to show the content of a local network drive pointing the root/documents directory to the second server. I can address the subfolders via the URL from my call from within Xojo and the port of the “fileserver”.
Disadvantages:
ugly like hell
and the can’t just easily drag&drop these files somewhere but they can open a file
There must be some kind of communication issue, because this is not what I thought you wanted either. My links and ideas aren’t quite relevant to listing a directory like this. Did you get what you needed working?
It wasn’t either what I originally wanted. But it is a (fast) workaround. I originally didn’t want to install a webserver at all.
They have currently an “Intranet” build on pure HTML pages. They open the index.html and as such calling network folders via an a href is still working (opens the Windows Explorer and points to the right folder. This is not possible with Xojo. But a separate Webserver can auto-index HTML pages of a folder, this is less “luxury” as showing the files directly in the Windows Explorer, where they can change them, drag them into an email etc. But at least I can now point them to the relevant folder.
well the downside is that anyone can list that folder.
1 Like
that’s true, but lucky enough this folder is public.
1 Like
