-
I am just trying to figure out if this is even feasibly possible (since I don't have any real experience in this area). Here is the situation:
We currently have a system that is basically all ASP webpages accessing some backend MS SQL and document management stuff (PCDocs). All user interaction for the system is handled via the ASP pages, except one piece which requires a stand alone VB app on each client desktop (this app also interacts with the same MS SQL database, checks documents out (from the DB) and appends a digital signature onto an MS Word doc, then checks the document back in. But it involves many manual steps to be performed by the user, like "Right click on the link and save the DOC file to your hard drive", run the VB app and point it to the DOC file you just downloaded, etc.).
What I would like to do is roll that VB code into an ActiveX component (or some combination of ASP and VB), present the user with a webpage that allows them to click a button which would then perform the entire task for them; check out the document, download it to their hard drive, append a digital signature, upload it back to the system, check in the document, etc.
What I wasn't sure of was whether or not an ActiveX component can be called from a webpage and if that component could then read/write files to the user's hard drive. I would imagine there are valid security concerns with this, but it is for an intranet only application.
Thanks for any pointers on this...
-
Does this need to be a web-based app?
I can see this being a much easier task (you wouldn't worry about having to interact with ASP) if you can create a standalone EXE to connect to your DB, get the document, append a signature, etc. etc.
IE default security is low for intranet sites, but even if your OCX causes IE to pop up a warning message, instruct your users to ignore the message. Once your OCX is on the users' system, you have full control over the system (just like you would with a normal VB EXE)
Tom
-
Thanks for the input... Yes, the solution is all web-based already (and it is using the CyberDocs product).
So, if an OCX can interact with the user's machine just like a regular VB program, technically this should be pretty straight forward. Now, practically speaking... I would imagine that this VB OCX I'd create would be roughly 50K (judging from the size of a similar VB .EXE and not including any support files). How smart is IE about "pulling" the OCX down to the user's machine? Does it do this once per session? And how do you handle updates to the OCX (ie, new version gets placed on the server, how does the client machine "know" about the new version)? Also, I would assume that we'd have to have some sort of installation process in place to load any special DLLs (used in the OCX component) to the client machine and probably to change their settings in IE to make sure they are setup to allow OCX components to be used.
