That's because you need a HTTP server to process HTTP requests and spawn CGI scripts.
Probably the easiest way to get this to work quickly is to use a simple HTTP server like the one I pointed to in my post), especially since you're apparently still using a default browser to look at the HTML pages (IE just embeds in the explorer window if you have it as the default browser) - you could just as well make a perl (or .bat) script that starts the HTTP server and then points IE to the start-page.
But maybe I'm just misinterpreting what you're saying....
| [reply] |
No not at all, you have the right train of thought going.
I just was not sure if a module was capable of converting the script to a standalone package.
I think the locally run server approach would be the best bet for this problem, though it means more fiddling with the host system. Not what i wanted but may have to suffice.
I will look into the TK::HTML pages also to see what theyhave to offer.
thanks guys and gals.
| [reply] |
Well, if you want your system to run locally, you're going to have to "mess" with the system: you need to install *some* software, after all..
I also recommend you check out PAR. By the way, if at all possible, you should probably use a standard browser instead of Tk::HTML; it'll save you a lot of extra hassle, and users don't have to learn yet another browser.
| [reply] |
what i meant was the windows explorer interface. The interface that runs Windows. Not internet explorer.
The Windows Explorer interface can't do arbitrary
things. It's just a file and folder management
interface; it does not do much of anything else
(okay so it does also display the taskbar...),
and specifically it doesn't do any of the things
you would normally use CGI for; it does not, for
instance display or process the results of
form elements. Mostly it copies files and launches
application processes. I'm pretty sure what you
actually meant was something other
than the Windows Explorer interface. I'm not 100%
certain what you did mean, but I'm pretty sure
that that's not it. There must be a
confusion of terminology (which is fairly common
when dealing with Microsoft stuff).
The question is whether you meant Internet Explorer,
or the Win32 widget set, or some other thing.
But you almost certainly
didn't mean Windows Explorer, at least not if you
have any real understanding of what Windows Explorer
is or does. My best guess is that you meant the
Win32 widget set (in which case, the answer is no,
converting from CGI to that is not easy, and you
should instead consider the other approach, which
others have discussed, of using a standalone
web-server module and allowing the user to use
Internet Explorer as the interface even though the
app is running on the local system, not remotely),
but that is only a guess, because you have not
described in precise detail exactly what you want.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply] |
The Windows Explorer, as in what you get when you press WindowsKey-E, is a subset of Internet Explorer since it became built into the operating system. If you pull up the Windows Explorer (WinKey-E) and then type "http://www.perlmonks.org" into the Address bar, it will load in the same window.
Setting up a CGI to run off a local HTTP server and then creating a shortcut that loads a "http://localhost/whatever" is not paticularly hard and the user experience will be what you want - its the installation of such a setup that is going to be a hassle. You will need to install ActiveState Perl and a local HTTP server on any machine you want to deploy to.
-Andrew.
| [reply] |
The windows explorer is also the windowmanager in MSWindows. To keep it confusing...
| [reply] |
In your position, I would probably install at least these:
- Install PAR
This will allow you to package your scripts into a self-contained "executable" (there's a bit more to it than that...).
- You will have to come up with a way to run a webserver locally, people have suggested for example HTTP::Daemon
- For BLAST searches locally, you will need to install the NCBI tools for windows: blast-2.2.11-ia32-win32.exe
or possibly netblast if you just want to blast against remote databases.
- Then, to make perl talk to blast, I think this might be
handy: Bio::Tools::Run::StandAloneBlast
| [reply] |