This is not a pick related question...

We would like to populate specific fields from a web form with data that
will exist in a file somewhere on the user's computer (similar to what
Roboform does but the data is generated on the fly).

More specifically we want to create a script that would run when the user
hits a function key.
It would prompt for a patient id number.
It would then execute a program (already written) that would generate
patient demographic data and place it in a specific directory.

[this much is done]

Now we want to parse that data, take about 10 fields from that file and
automatically fill out the web form (that is already open).

Has anyone done this or can you help us develop this? The need is
immediate.

You can email me directly or reply to this forum.
jcaspariremovethisss (AT) labheath (DOT) com

Thanks very much!
Jeff

On 2010-10-06 10:14:20 -0400, "Jeff Caspari" <munge (AT) idt (DOT) net> said:

Jeff,

A quick search turned up a couple of products that might work for you.

http://www.iopus.com
http://www.inetformfiller.com

HTH
--
Kevin Powick

Thanks Kevin.

Since your post we have been working with the iopus software which seems to
have 'imacros' that can do exactly what we need. It's taking a while but we
are making progress.

However, if anyone can do this I would be happy to pay them for a solution.

Jeff

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

I reviewed iOpus as a possible tool for automation of DesignBais form
testing. I was impressed with the software and the company's interest
in assisting.

I will note that our use of this interweb thing has taken many turns
over the years. One of the primary reasons why there has been a trend
toward the browser as the universal client is because it's already on
the desktop after initial installation by a sysadmin, and "supposedly"
there's no other software to install.

I say supposedly because in practice there's always something being
installed. Some people are adverse to plugins, whether Flash or
Silverlight. But that flies in the face of enthusiasm for all of
those wonderful addons for FireFox that people use, not to mention the
Adobe Acrobat Reader and other "gotta have it" utilities.

Admins don't want to install thick-client GUI because it's an
administrative hassle, so they prefer the thin-client browser. Let's
ignore the fact that most software these days is self-updating and
doesn't require manual administration anymore anyway.

And now here we find an application where some data on the client PC
needs to be fed into that browser with a utility installed on the PC -
completely undermining the raison d'être of the browser UI in the
first place. I'm not saying it's entirely wrong, I'm just making an
observation about what we've done to ourselves by maintaining certain
attitudes about how things should or should not work.

Jeff, to this specific application. My recommendation is not to do
what you're trying to do. There is too tight a bond between the
client software and your browser UI. Another one of the reasons for
the browser is that it allows deployment entirely on the server for
immediate updates. You're losing this advantage by putting software
on the client that depends on the UI looking a specific way.

My recommendation is that you do one of the following:
1) Create a utility that runs in the tray of the user PC, and extracts
data and pushes it across the net to a web service on your server.
You can then do whatever you want with that data. There is no binding
to a UI and a LOT less can go wrong here. This utility can be
self-updating and will not require any administration.
2) You can create a Silverlight or Flash addin which runs in any
browser. It has virtually no UI. It will initially request
permission to access the client PC file system and from then on it
won't bother the user. When you serve up this component transparently
in one of your pages it will extract data and push it out to your
server. You can then refresh the browser with the data. Again, the
data and the UI are completely separate. The advantage here is that
there is nothing running on the client PC, nothing even installed, and
you can change your addin as required.

I know that doesn't fall within the expertise available at your
company, but that shouldn't preclude what may be the right solution
for the challenge at hand.

I'm curious about what people think about this.

HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET worldwide
and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno



Kevin Powick wrote:

On 2010-10-08 17:21:01 -0400, Tony Gravagno <nospam (AT) nospam (DOT) invalid> said:

I pretty much agree with what you said for the reasons given. The
biggest of which is the potential problem of what happens when the
browser UI changes.

Keeping everything running from the browser is smart, but there are
alternatives to Silverlight. Presumably, the user has to select some
data file from some folder on their workstation, so a simple JavaScript
"upload file" routine, possibly combined with a little Ajax, would work
as well too.

I know there are other alternatives, but JS is likely one of the
easiest to implement.

--
Kevin Powick

Not surprising

Actually, if we don't have the expertise and no one is offering to do this
and this needs to get done immediately it pretty much does preclude your
'right solution'.

I love you Tony but we live in the world of production, now.

Jeff

On 2010-10-09 08:57:42 -0400, "Jeff Caspari" <munge (AT) idt (DOT) net> said:
LOL!

--
Kevin Powick

If the file containing the data is available via http:, I'd create a
script that extracts what is needed, formats it in JSON, and then use
Ajax from the browser to load the content and turn it into a first-
class Javascript object. At that point it's no big deal to populate
an open web form. And with an Ajax library such as what is included
with jQuery, it's not difficult at all and completely cross-browser
compliant.

On Oct 6, 7:14*am, "Jeff Caspari" <mu... (AT) idt (DOT) net> wrote:
I'm probably not understanding this request, but why can't you do this
using PHP?
Because it can't read a file on the user's computer?

We're not familiar with it. Can it read a file on the user's computer?

If you think you can do this or please call me at 845-352-4313 ext.14

Thank you!
Jeff