I agree with most of your points. I think the main problem you're going to run into is Win32::GUI is a Perl module, so requires some Perl to use it. If you want it to run on a system that doesn't have Perl installed, then that won't work without compiling it some fashion. (Aldo's example at with WSH would require Perl to be installed.) In the case of TK - it had to be ported to the language it is used with in most cases, whether that be Perl, TCL, or whatever. In theory - you could do something similar with Win32::GUI but it would take quite a bit of development (and Win32::GUI is still in beta!!). An alternative approach that may be easier to achieve and would be more flexible would be to compile Win32::GUI into a ActiveX component (or COM object if you prefer..) using ActiveState's DevKit and then use VBScript(or any other language that can access COM, including Perl ;-) to make calls to that object. This would likely require some changes to Win32::Gui and I'm not sure how reliable ActiveState's Com builder is.. - but the result would be a simple dll that could be distributed and that would allow scripting languages access to Win32::GUI's widgets. It would be interesting to here what Aldo thinks on all of this..... Aldo?? Hope this helps, Christian [EMAIL PROTECTED] > -----Original Message----- > From: David Welden [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 19, 2000 3:03 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: [perl-win32-gui] Win32:GUI accessible from other > scripting > la nguages? > > > My final goal is to be able to GUI-enable VBScript or JScript > or .... as > opposed to using a bloated, overkill language like Java or VB > or C++; many > of the tasks I script just don't need all of that extra > stuff. A compiled > executable is not at all what interests me. > > Win32:GUI demonstrates to me that one can generate GUI > applications without > the overhead of a compiled application. But I would like to > have the freedom > to do so with other scripting languages. Don't want to start > a religious war > over this, I just have reasons for wanting to use > alternatives to Perl. > Win32:GUI could potentially be developed as a generic Win32 > GUI-enabler for > any scripting language just as TK has been modified to > GUI-enable things > outside of the TCL world. > > So why don't I just use TK? Win32:GUI seems to be cleaner and lighter > weight. I don't care about developing for Eunuchs, OS/2, > etc.; Windows is > where I work. > > Yes, I may be mixing tools, just like the folks who have > managed to get TK > and Perl talking. Why limit yourself to the confines of a > single tool? We > would not have GUI Perl if we did. Mixing tools is what XS is > all about. > > ------Original Message------ > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > Sent: July 19, 2000 3:52:47 PM GMT > Subject: RE: [perl-win32-gui] Win32:GUI accessible from other > scripting la > nguages? > > > I'm confused as to what your final goal is... That makes it > harder to advise > you... > > At this point it looks like you are trying to mix several > different tools > together, but I'm not sure why or what you are trying to avoid.... > > If you are just looking to make a standalone executable that > will run on a > machine without Perl installed, then I would suggest looking > into Perl2Exe > which will compile a Perl program into a standalone executable. > > If you are trying to use Win32::GUI without having to learn > or use Perl, > then I think you are going to be out of luck. > > Hope this helps, > Christian Lobaugh > [EMAIL PROTECTED] > > > > -----Original Message----- > > From: David Welden [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 18, 2000 1:52 PM > > To: Aldo Calpini > > Cc: [EMAIL PROTECTED] > > Subject: Re: [perl-win32-gui] Win32:GUI accessible from other > > scripting > > languages? > > > > > > OK, harder question. Assuming I can make dll calls from > > VBScript (which I > > can with a wrapper OCX I have), can I access Win32:GUI > > directly (no Perl > > script)? By the way, this would be a standalone WSH script, > > not a web/HTML > > embedded script. > > > > The server I need to work on does not have Perl and probably > > never will > > (long story, no point in retelling). Visual Basic would be > the obvious > > choice for this, but I want to avoid that option if I can. > > > > ------Original Message------ > > From: Aldo Calpini <[EMAIL PROTECTED]> > > To: David Welden <[EMAIL PROTECTED]> > > Sent: July 18, 2000 2:34:27 PM GMT > > Subject: Re: [perl-win32-gui] Win32:GUI accessible from other > > scripting > > languages? > > > > > > David Welden wrote: > > > Thanks for the swift reply. WSH 2.0 is exactly what I > > > have in mind. Any suggestions/pointers/redirects to other > > > resources on the process? > > > > the resource: http://msdn.microsoft.com/scripting > > > > basically, in WSH 2.0 you create a file, say named > > script.wsf and put in: > > > > <Job id="sample"> > > <script language="PerlScript" runat="Server"> > > use Win32::GUI; > > sub CreateWindows { > > # ...put all your stuff here > > ); > > </script> > > <script language="JScript" runat="Server"> > > CreateWindows(); > > </script> > > </Job> > > > > the available samples do not show if, and how, you > > can share variables between scripting engines, or > > how you can call a Perl function in another package > > (eg. MyPackage::CreateWindows). > > I will eventually make some testing here and let > > you know... > > > > cheers, > > Aldo > > > > __END__ > > $_=q,just perl,,s, , another ,,s,$, hacker,,print; > > > > > > ----------------------------------------------- > > FREE! The World's Best Email Address @email.com > > Reserve your name now at http://www.email.com > > > > > > > ----------------------------------------------- > FREE! The World's Best Email Address @email.com > Reserve your name now at http://www.email.com > >
