despo said:
Thank you for not deleting the attribution lines next time, and for posting
the followup exactly to what you are referring to, not just somewhere in the
thread as you did here.
OK, I got the impression that ActiveXObjects worked only for IE.
They do not. What matters are the capabilities of the runtime environment,
not the name of the browser.
I am interested mainly for firefox (meaning i want what this web page to
work in any environment, but if it cannot, i would prefer it to be
functional in firefox).
In that case you might want to look into XPCOM, the Cross-Platform Component
Object Model provided by Mozilla. It can be used in a privileged
environment, like a Gecko-based application which would use XUL.
i tried to set e4x in the script declaration, but it does not seem to
change anything. And somewhere i read that it is not needed.
IIRC, it is no longer needed for recent versions of Firefox.
So you mean, I should create a file, which will be used to write on
data temporarily.
I do not know yet what exactly you want to accomplish, so I have not made
any recommendation yet.
Then if I guess I have to allocate some space for its potential size,
right? How can i do that?
Try to clarify what you are trying to accomplish before jumping to further
conclusions.
Well, I understand that an user that uses a web site for some
calculations cannot have the permission to write in the server that
hosts the web site.
That is incorrect if "write in the server" means "write access to the
server's filesystem". A user can be granted restricted access to certain
areas of that filesystem if necessary.
But what if the user had the permission to create a temporary file;
They already have: on the client-side, in memory, so to speak.
then if he wants to save it in his hard disk, then he has the possibility
to do it, otherwise the file would be deleted permanently. I believe there
must be such a possibility,
Now we are finally talking. So you want the *user* to initiate the Save
operation? That can be arranged. Using DOM methods (but with XML, better
not document.write()) is the first step to a client-side solution, creating
a temporary document in memory (not a file), which can be saved as a file in
the user's local filesystem.
it's only i don't know how to explain it better. Imagine some form you
submit with your personal data. On submission, the data are processed
somehow, but also the user has thew right to see what he filled in in
this form.
But that is what *server-side* scripting has been devised for. Assuming you
want to store the submitted data somewhere on the server-side, you should
generate, with a server-side application, in the same process, an XML
document that contains the submitted data, and serve it via HTTP (either
automatically or on user request). Because you cannot be sure that the data
was successfully transmitted from the client side. How you would do it
would depend on your server-side environment.
I think that this is what i describe above, isn't it? Data formatted
as xml sent saved in the user's hard disk,
Saving files, however, is usually something that only a user can do, on the
client-side. You/the server side can only provide the data to be saved.
or sent to an email address.
That needs to be done from the server-side instead because you cannot assume
the user has a suitable e-mail client installed or, if installed, that you
could trigger it from the Web browser or another application.
PointedEars
), then maybe