Hey all. I made a library that allows the user to import files from their computer. Here is a project demonstrating this:
https://snap.berkeley.edu/project?user=pumpkinhead&project=file%20import
Cool!
That's very impressive! With text files, I really wanted the text captured in a variable, not just an ephemeral speech balloon. You could make a variable named after the file name (minus extension). If there's already a variable by that name, append "(2)" or whatever number that name is up to, as for sprites or costumes.
I haven't read your code carefully, but I got the impression that there can only be one pending input of a given type, even though your library offers an asynchronous interface. Am I right?
No, it isn't async. The read file block reads a given file as a certain type, then it yields the thread until the result is returned by the block.
Yes, I was thinking about this thread while eating breakfast and realized that the ask for files block is async. And it only is because it is impossible to determine if the user actually submitted or cancelled. So the ask for file and wait block continues the thread if a user submitted a file. If a user cancels, then it will yield indefinitely.
But my question is, what if another script meanwhile asks for another file? So now there are two OS file-open windows onscreen. Could the first script end up with the second script's file or vice versa?
For me, it opens the next window after the first window has closed. So I guess if some guy with malicious intent wrote a never-ending loop with the the import files block the user would have to make a new window so they can open the browser's task manager to close the tab. I can't find a way to prevent multiple pending inputs from happening at the same time because I can't actually confirm whether a user submitted or cancelled.
As a result of your previous question, I changed the code a bit so you can detect if the user imported new files.
So the way I programmed it is that it fires the click event on a hidden file input DOM element. The onchange event is hooked up to broadcast the "file input changed" event. The imported files reporter will report the newest files given from the input. Since I have no way to confirm if a user actually pressed submit or cancel, only if their submitted files have changed, the import files block is async and does't return anything. The imported files reporter outputs the imported Javascript File objects.
So the imported files reporter will only report the latest imported files.
I should really be trying this instead of asking questions, but I'm too lazy right now.
Thread A asks to open a file and gets an OS file dialog.
Then thread B asks to open a file and gets another OS file dialog.
Now the user types a filename and OK in the second dialog.
Does the first dialog see that? If it's one hidden DOM element per thread, it should be okay, but if it's one global element then it should, I think, mess up. (What should happen is that each thread sees the result of the OS dialog that it started.)
On Chrome, only one file input window shows up. The other one shows up after the first window closes. I don't know how it's like on Firefox or another browser.
Anyway, the reporter that reports the imported files is global, so there can only be one result, which is the latest batch of files imported. So the first dialog will see the second's in your situation.
I wanted the ask for files block to behave similarly to the ask [] and wait block
That has the same problem, in principle, although Jens has things worked out so that something comprehensible happens. But ask and wait is the wrong way to do it; we should have ask as a reporter that reports the answer to this question that you give it as input, regardless of the order in which the user answers questions. And the same with when I receive any message which (this is in the works) will have an upvar for the message it is processing.
I was thinking of making the file input block a reporter. But I decided to make it a command because if I made it a reporter, the reporter would have to wait until the user presses submit or cancel. And there is no definitive way of confirming that. I'm not sure why it is that way.
To mirror the underlying browser control flow, what you really have to do is have it be a command but have it take as input another (callback) procedure that will be invoked when a result comes back. But really I think making it synchronous is fine, since having a thread "on hold" won't stop other threads from running.
Cool library!
is there a way to show the contents of an archive, like a zipped folder?
No, unless you write a zip parser or use someone else's
ok
In what context? I think most operating system desktops let you open an archive as if it were a folder, and then you can copy stuff out etc.
yeah, they do, with zipped folders, but I want to be able to do it using code.
Ah. I bet there are libraries... ask DuckDuckGo.