Re: Calling Perl script from windows form
by Anonymous Monk on Apr 30, 2014 at 07:23 UTC
|
Tk/Tcl::Tk/Tcl::pTk/Tkx, Tk::Zinc, Wx, Prima, IUP, Gtk/Gtk2/Gtk3, Gtk2Fu, Qt/QtCore4, FLTK, Java::Swing...?
Perl GUI (2013)
I like Wx :) Re: wxPerl: is BitmapFromImage implemented? (no;sleep;docs), my wxWidgets / wxPerl / wxGlade tutorial, http://www.wxperl.it/p/wxperl-primer.html , wxperl_usage / wxperl-usage / wxPerl::Usage / Class Method Browser , available methods, method invocation syntax, link to docs, Re^8: How to use wxHtmlEasyPrinting (On debugging, verify everything, talk to teddybear ... and links and links , Tutorials: Perl documentation documentation, Searching Perl Documentation you don't need to build wx yourself, http://www.citrusperl.com/, http://ppm.wxperl.it/ What Do These Sizer Things Do?
perl Tk help, RFC: Learning Perl/Tk, Perl/Tk: For Beginners, Re^3: Tkx Search for dialog box for text input , Re: TclTk interface with Perl code, is it possible? , Re^2: GUI toolkit+designer for the perl newbie , Re: Easier GUI, Re: Should I use Perl/TK?, Re^2: need a popup gui stdin, Tk Tree Tutorial ( http://www.rtapo.com/tutorials/tk_tree.html ), some Tkx tutorial links, Tutorial http://theoryx5.uwinnipeg.ca/perltk/ and http://www.perl.com/pub/1999/10/perltk/, http://perltk.org/, http://web.archive.org/web/20100310202528/http://theoryx5.uwinnipeg.ca/perltk/, How to RTFM Tk Tutorials
| [reply] |
|
|
I know that, but I REALLY wanted to combine my perl script with C#. I guess I need to use command line.
Thanks anyway :)
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
Re: Calling Perl script from windows form
by Anonymous Monk on Apr 30, 2014 at 11:17 UTC
|
You can run external programs from C#, a quick Google brings up, for example, this. You would be calling perl.exe (or wperl.exe) with the appropriate arguments, i.e. the pathname of your script and any other arguments.
I've found it's helpful to use absolute pathnames, and also to write the script such that it does not make any assumptions about the current working directory (it can use FindBin to figure out its location). A caveat: Using full pathnames means that those need to be hardcoded or configured, making the application a little less easy to move between differently laid out machines. I've found that in a somewhat controlled environment, full pathnames have been more helpful than not, others may disagree.
As for really "integrating" Perl into C#, as in integrating an interpreter into your application, I'm not sure if that's possible or how easy or not it is. Maybe some other Monks have some experience on that. Apparently ActiveState offers some kind of .NET "integration".
Lastly, as the other anon has pointed out, you can write GUIs in Perl (but then they wouldn't have anything to do with C#).
| [reply] [d/l] [select] |
|
|
| [reply] |
Re: Calling Perl script from windows form
by locked_user sundialsvc4 (Abbot) on Apr 30, 2014 at 11:54 UTC
|
As the latest Anonymous Monk did usefully say . . . from the point-of-view of your GUI application, the Perl script is simply an external program. You simply need to build a command-line string containing the name of the script and any parameters, and execute that as you would any other external process. If, as I expect, ActiveState has associated itself with the .pl filename extension, you ought to be able to just execute the script-file name. (Naturally, you should start by fiddling-around with the proper way to do just-that within C#, until you get the necessary magic-spell just right.)
One issue, though, will be coming up with an appropriate way for your GUI application to wait for the external process (the Perl script) to complete, without hanging-up the user interface as GUI-programs must never do. Of course the Internet should be filled with examples of how to do that part. (“Don’t sweat it, don’t [re-]invent it, just google find it ...”) It really does not matter that the external program in question is written in Perl or anything else. Then, carefully look for any discussions on the Internet that may particularly relate to ActiveState-specific issues in this case.
Kindly observe that the external program (the script) will be a direct child-process of the GUI process: it is not running under (Windows’s pathetic excuse for) a command-shell.
| |
|
|
| [reply] |