2

I have done quite a bit of searching but cant seem to find a up to date answer.

I am currently rewriting an application that was written in Perl. So I'm not starting from scratch.

The application currently already has a basic GUI which is written in C# .net ,but one of my goals is to create a new and improved GUI. This GUI has to implement a couple of features so it would really ease my workload if I could use a GUI builder like in .net

Now my question:

I would like to separate the GUI and the Perl logic. So in theory it should work if the GUI i create just calls the various Perl scripts -> which do something and then return something to the GUI.

Has anybody had any experience in using a C# .net created GUI to interact with various Perl scripts? If yes could you tell me some positive or negative stuff you have noticed during your experience.

I have also been playing around with tkx. I suppose i could use this, but it would defiantly increase development time. Would anyone know a GUI builder that generates perl tkx code?

I have also looked at others like TK,QT,... but the main problem is that they all have dependencies.

I would appreciate any advice. thanks

Ivan Bacher
  • 5,855
  • 9
  • 36
  • 56

2 Answers2

1

ActiveState seems to have released to sourceforge a program named GUI Builder. It appears to be compatible with Perl, Ruby, TCL & Python.

tjd
  • 4,064
  • 1
  • 24
  • 34
1

Do you want to have a new gui in C#? The Visual Studio has a gui builders for WinForms and WPF. WinForms builder is quite OK, but the WPF one is rather a piece of crap and it's better to "handcode" the XAML code yourself and use the builder only for visualizing what you are building. For serious work with animations/templates I recommend the Blend.

I have never executed the perl scripts, but the process will not be different for executing other external programs, if your perl interpreter does not have a decent .Net api.

For executing scripts in "standard way" you can use the Process class from System.Diagnostics namespace. You can put in the command line arguments or stdin and read stdout and stderr. The only thing you should worry about is that if the external program hangs, puts something to stderr but does not end, you can be stuck. You should read stdout and stderr of the script simultanously (each in separated thread) and the Process should be also instantiated and run in own thread - so you will not hang your application and you can monitor the process and offer user the "cancel" button.

Good thing for this is BackgroundWorker class from System.ComponentModel.BackgroundWorker namespace which can handle a lot of "low-level thread things" itself

eMko
  • 1,147
  • 9
  • 22
  • Thanks for the reply. Yeah while a was waiting for n answer i was doing some things with the Process class. This seems to be functioning pretty well. Putting everything in its own threads seems to be the right way to go. I will defiantly use the info you have posted – Ivan Bacher Jun 04 '13 at 13:56