In our solution INtex Office instead of printing we generate HTML files and export them. The user can then decide whether he wants to print these or open wie Excel or Word.
We have the technology to create all and any PDF that you want using ScriptMaster and iText on the server.
Advantage is that it works on Go too.
And can do so much more that you imagine, like digitally signing the finished file.
Thanks, currently I am in favour of two solutions:
1. Digital Fusion / RoboPrint
... but here I am stuck because in v14 WebDirect it let me only print one page, not the Found Set
... and here I am stuck because of the complexity of the sample file Can't see the wood before the trees.
I like the idea of triggering a remote script from WebDirect on a remote robot machine by 'OnRecordLoad'. But I just do not get it working.
Anybody able to help?
Has anyone tried the MBS/DynaPdf plugin combo?
Both are WebDirect compatible so it should be possible to create and display a pdf in a container or download it.
ScriptMaster and iText cheaper combination, and more powerful
Richard Carlton did a nice video explaining the demo that you mention in 2 - the Clickworks file. Check on youtube for it, it is worth a watch.
Basically, you need to run a script that creates a "session" record on open and keeps it in a found set of 1, but the record will not be locked.
When you delete that record from another client, that triggers the OnRecordLoad trigger to fire on the first machine, because that record is no longer there and it needs to show the next one (or none, but the trigger still fires). In the script that runs, put the "session" record back in place for the next time.
This works even if you open a new window for the "session" record and move it off screen or hide it. Also works in webdirect and FM Go, but for a robot it should work well. You may also want some other scripting to make sure this file is open on the robot and not hung up, but this is a great option, I think.
After using RemoteScripter for years, we moved to the ClickWorks solution. The reason was that we needed a solution without using a port number, as our corporate customer were not able to manage their firewalls. With the ClickWorks solution, all requests are running on port 80, which is kept open by the corporate IT.