On Oct 20, 8:15 pm, Special Access <nonyabidn...@hotmail.com> wrote:
> I am looking for an IDE for vbscript that I can debug, stop, run > line-by-line etc. Someone recommended Notepad++, but it appears to be > only an editor. > Free or at cost, all suggestions are welcome.
> Thanks! > Mike
You may or may not like the answer, but at this point in time I think you would be better off learning powershell than vbscript. There are some decent tools for that up and coming, that also probably work with vbscript. However, vbscript by nature is not very debug capable due to its rudimentary error catching. I use Notepad2 for my vbscripting now, but its not an IDE in the way you are looking for. If you are experienced in vbscript, then go for it, but if you are learning new, then powershell is the future.
> On Oct 20, 8:15 pm, Special Access <nonyabidn...@hotmail.com> wrote: >> I am looking for an IDE for vbscript that I can debug, stop, run >> line-by-line etc. Someone recommended Notepad++, but it appears to be >> only an editor. >> Free or at cost, all suggestions are welcome.
>> Thanks! >> Mike
> You may or may not like the answer, but at this point in time I think > you would be better off learning powershell than vbscript.
probably.
> There are > some decent tools for that up and coming, that also probably work with > vbscript.
One of these it PrimalScript.
> However, vbscript by nature is not very debug capable due to > its rudimentary error catching. I use Notepad2 for my vbscripting > now, but its not an IDE in the way you are looking for. If you are > experienced in vbscript, then go for it, but if you are learning new, > then powershell is the future.
> > However, vbscript by nature is not very debug capable due to > > its rudimentary error catching. I use Notepad2 for my vbscripting > > now, but its not an IDE in the way you are looking for. If you are > > experienced in vbscript, then go for it, but if you are learning new, > > then powershell is the future.
> Agreed.
I find that an odd opinion. I've always found VBS to be highly debuggable, even with very complex scripts. It's not so complex that it even needs the sort of debugging tools the OP is asking for. Thefact that WSH and IE can tell me the type of error and the line it's on has always been plenty for me. If someone can't work with that they're probably in over their head with the script they're writing.
I also don't understand the logic of comparing Power Shell to VBS/WSH. The former is a command line tool that's designed to mimic Unix/Linux console shells. VBS is designed for use with COM objects, as interpreted code, for use in automating software programs, and for IE scripting. They're completely different tools. Ironically, that was how WSH got its start in the first place. People wanted something more adapted for use with the "modern" GUI than DOS command line and BAT files. Now DOS is being updated, in a sense, to be a more functional command-line tool. But that realy has little to do with GUI scripting.
Powershell is good for single tasks. It has a lot of powerful info gathering and can pipe the data to several formats automatically. VBScript is good at automating several tasks into one larger script. I prefer to use VBScript for everything.
My IDE of choice is PrimalScript. There are cheaper alternatives but PrimalScript packs all the good features into one IDE. For example, it has script packaging which is quite handy in an enterprise environment. It also has code organization, code folding, quick lists (for subs and functions), and much more. When you write as many scripts as I do, you start to love these features. Oh and the ability to save your subs and functions as snippets is great.
On Oct 20, 11:43 pm, "mayayana" <mayaXXy...@rcXXn.com> wrote:
> > > However, vbscript by nature is not very debug capable due to > > > its rudimentary error catching. I use Notepad2 for my vbscripting > > > now, but its not an IDE in the way you are looking for. If you are > > > experienced in vbscript, then go for it, but if you are learning new, > > > then powershell is the future.
> > Agreed.
> I find that an odd opinion. I've always found > VBS to be highly debuggable, even with very > complex scripts. It's not so complex that it > even needs the sort of debugging tools > the OP is asking for. Thefact that WSH and IE > can tell me the type of error and the line it's > on has always been plenty for me. If someone > can't work with that they're probably in over their > head with the script they're writing.
> I also don't understand the logic of comparing > Power Shell to VBS/WSH. The former is a command > line tool that's designed to mimic Unix/Linux > console shells. VBS is designed for use with COM > objects, as interpreted code, for use in automating > software programs, and for IE scripting. They're > completely different tools. Ironically, that was how > WSH got its start in the first place. People wanted > something more adapted for use with the "modern" > GUI than DOS command line and BAT files. Now > DOS is being updated, in a sense, to be a more > functional command-line tool. But that realy has > little to do with GUI scripting.
>I am looking for an IDE for vbscript that I can debug, stop, run > line-by-line etc. Someone recommended Notepad++, but it appears to be > only an editor. > Free or at cost, all suggestions are welcome.
> Thanks! > Mike
I use SystemScripter 6.0. It has the usual features such as the ability to step through programs, view variables, automatic expansion of objects and methods, break points.
>> > However, vbscript by nature is not very debug capable due to >> > its rudimentary error catching. I use Notepad2 for my vbscripting >> > now, but its not an IDE in the way you are looking for. If you are >> > experienced in vbscript, then go for it, but if you are learning new, >> > then powershell is the future.
>> Agreed.
> I find that an odd opinion. I've always found > VBS to be highly debuggable, even with very > complex scripts. It's not so complex that it > even needs the sort of debugging tools > the OP is asking for. Thefact that WSH and IE > can tell me the type of error and the line it's > on has always been plenty for me. If someone > can't work with that they're probably in over their > head with the script they're writing.
Agreed.
> I also don't understand the logic of comparing > Power Shell to VBS/WSH. The former is a command > line tool that's designed to mimic Unix/Linux > console shells. VBS is designed for use with COM > objects, as interpreted code, for use in automating > software programs, and for IE scripting. They're > completely different tools. Ironically, that was how > WSH got its start in the first place. People wanted > something more adapted for use with the "modern" > GUI than DOS command line and BAT files. Now > DOS is being updated, in a sense, to be a more > functional command-line tool. But that realy has > little to do with GUI scripting.
I basically agreed with the statement that "powershell is the future" because I think that the paragraph I was replying to got it right. VBScript is great for VBScripters. But someone with no knowledge of any of these technologies would, in many cases, be better off starting with powershell.
I agree that this is an almost apples and oranges comparison. But that is owing more to the significant differences between the two platforms than a significant difference in the areas of application. Most of my vbscripting has been in the area of system management, and that is one of the main problem spaces that powershell was developed for.
That said, I have to keep reminding myself that vbscript itself runs in environments other than WSH (like .html and .hta), as I was just about to take exception to your comment about GUI scripting.
>I am looking for an IDE for vbscript that I can debug, stop, run > line-by-line etc. Someone recommended Notepad++, but it appears to be > only an editor. > Free or at cost, all suggestions are welcome.
Don't overlook the IDE in any of the Microsoft Office products. It will work perfectly fine with VBS.
I find Textpad to be an excellent editor. Good syntax highlighting. As for Powershell, I initially found the transition from "traditional" programming styles (WSH VBScript etc.) to PS a little troublesome. Quite a thinking shift. Now that I'm mostly there, I love it. PS is VERY powerfull and the interactive nature makes testing code bits very easy.
If you're new to scripting, go straight to Powershell. For IDE's I prefer Quest's Powershell Editor.
> "Special Access" <nonyabidn...@hotmail.com> wrote in message > news:n1osd5ht4d3745nmndovrfbvhkd40dpfte@4ax.com... >>I am looking for an IDE for vbscript that I can debug, stop, run >> line-by-line etc. Someone recommended Notepad++, but it appears to be >> only an editor. >> Free or at cost, all suggestions are welcome.
> Don't overlook the IDE in any of the Microsoft Office products. It will > work perfectly fine with VBS.
> Most of my vbscripting > has been in the area of system management, > and that is one of the main > problem spaces that powershell was developed for.
> That said, I have to keep reminding myself that > vbscript itself runs in > environments other than WSH (like .html and .hta), > as I was just about to > take exception to your comment about GUI scripting.
Yes, I often think of it as several languages. For Word automation, IE automation, ASP, WSH.... They're all VBS but with very little overlap in terms of objects used. And HTA's are really GUI software. I often use them for little programs where the rigor and time required to write compiled software is just not necessary or worthwhile.
But I also meant GUI scripting as a term to distinguish WSH from console tools like DOS/PowerShell. WSH was developed (mostly in response to sys. admins, I think) as the Windows (GUI) alternative to DOS. It updated scripting to add drag/drop, COM, and various amenities that a GUI system can provide. DOS was designed for a pre-GUI OS.
I think console vs GUI is a helpful distinction. Some people prefer "console scripting", some prefer "GUI scripting", some use both. But they're two entirely different things. There's a humorous irony in the idea that anyone would think console scripting is the updated, new replacement for GUI scripting. :)
One of my complaints with Linux is that while it's elevated console scripting to an art form, there seems to be nothing in terms of GUI scripting. (The GUI itself seems to be little more than a science fair project to this day, with many of the people developing Linux being people who prefer to work in the console version.Though I have found that the WSH can be installed and VBS can work just fine under Wine.)
> I basically agreed with the statement that "powershell is the future"
Thinking about that... What I'd really like to see is for MS to provide a full set of COM interfaces to .Net. Then it would be scriptable. We're in a funny in-between place now. Windows is COM and looks like it will be for the foreseeable future, yet MS is moving .Net right into Windows by doing things like adding .Net support to PowerShell. So it'd be nice if they'd take it full circle and incorporate .Net fully with COM.
>> Most of my vbscripting >> has been in the area of system management, >> and that is one of the main >> problem spaces that powershell was developed for.
>> That said, I have to keep reminding myself that >> vbscript itself runs in >> environments other than WSH (like .html and .hta), >> as I was just about to >> take exception to your comment about GUI scripting.
> Yes, I often think of it as several languages. For > Word automation, IE automation, ASP, WSH.... > They're all VBS but with very little overlap in terms > of objects used. And HTA's are really GUI software. I > often use them for little programs where the rigor > and time required to write compiled software is just > not necessary or worthwhile.
> But I also meant GUI scripting as a term to distinguish > WSH from console tools like DOS/PowerShell. WSH was > developed (mostly in response to sys. admins, I think) > as the Windows (GUI) alternative to DOS. It updated > scripting to add drag/drop, COM, and various amenities > that a GUI system can provide. DOS was designed for a > pre-GUI OS.
> I think console vs GUI is a helpful distinction. Some > people prefer "console scripting", some prefer "GUI > scripting", some use both. But they're two entirely different > things. There's a humorous irony in the idea that anyone > would think console scripting is the updated, new > replacement for GUI scripting. :)
And yet some humorous ironies have an annoying habit of sometimes actually being true...
> One of my complaints with Linux is that while it's > elevated console scripting to an art form, there seems > to be nothing in terms of GUI scripting. (The GUI itself > seems to be little more than a science fair project to > this day, with many of the people developing Linux > being people who prefer to work in the console > version.Though I have found that the WSH can be installed > and VBS can work just fine under Wine.)
In some ways, GUI scripting could be considered an oxymoron.
My first couple of MVP awards were in a category that, IIRC, was "visual developer - scripting". In my bio I pointed out that all of my scripting was virtually invisible ;-)
That said, coming from a DOS/batch and VMS background, I find GUI-based administrative tools generally disappointing when compared with straight (invisible) scripting where the limitations of the GUI tools can be surpassed with a bit of clever work.
Of course, your term "GUI scripting" is not necessarily scripting with a GUI tool so much as creating a GUI tool with scripting.
VBScript has only two intrinsic GUI capabilities: MSGBOX and INPUTBOX. When combined with dynamic html code in an html page or hta application, the sky becomes the limit.
Powershell, on the other hand, has no built-in GUI widgets (I think). But it too can drive a GUI using a number of technologies such as, I believe, winforms.
When it comes to administering windows systems, however, Powershell may have the advantage for some of us, as it does not need external COM objects to interface with windows.
>> I basically agreed with the statement that "powershell is the future"
> Thinking about that... What I'd really like to > see is for MS to provide a full set of COM interfaces > to .Net. Then it would be scriptable. We're in a funny > in-between place now. Windows is COM and looks like > it will be for the foreseeable future, yet MS is moving > .Net right into Windows by doing things like adding > .Net support to PowerShell. So it'd be nice if they'd > take it full circle and incorporate .Net fully with COM.
They may indeed be increasing the accessibility of .net capabilities to powershell scripters. But don't forget that PowerShell was built on the .net runtime, and, in fact, cannot operate on a system not having .net installed.
>> > However, vbscript by nature is not very debug capable due to >> > its rudimentary error catching. I use Notepad2 for my vbscripting >> > now, but its not an IDE in the way you are looking for. If you are >> > experienced in vbscript, then go for it, but if you are learning new, >> > then powershell is the future.
>> Agreed.
> I find that an odd opinion. I've always found > VBS to be highly debuggable, even with very > complex scripts. It's not so complex that it > even needs the sort of debugging tools > the OP is asking for. Thefact that WSH and IE > can tell me the type of error and the line it's > on has always been plenty for me. If someone > can't work with that they're probably in over their > head with the script they're writing.
> I also don't understand the logic of comparing > Power Shell to VBS/WSH. The former is a command > line tool that's designed to mimic Unix/Linux > console shells. VBS is designed for use with COM > objects, as interpreted code, for use in automating > software programs, and for IE scripting. They're > completely different tools. Ironically, that was how > WSH got its start in the first place. People wanted > something more adapted for use with the "modern" > GUI than DOS command line and BAT files. Now > DOS is being updated, in a sense, to be a more > functional command-line tool. But that realy has > little to do with GUI scripting.
I'm happy with the VBscript. I'm in the application arena, not system administration. Pretty much basic programming, semi-automating some desktop stuff. VBscript seems very similar to Visual Basic for Applications (VBA), macros for Hummingbird, macros for Attachmate, and can be inserted into hta's along with javascript. All of these I use. Right now, we're on the XP platform, and I think IT is going to skip Vista and go to Windows 7, but unless Windows 7 is going to exclude vbscript, it will be useful to me. In particular, unless powershell can be dropped into an hta with similar functionality as VBscript, I don't see an awful lot of use for it. I'm going to check, but I don't think it's installed on any of the work PC's running XP. But, once we cut over to Windows 7.... (which won't happen until a service pack or two ;-)
>> I basically agreed with the statement that "powershell is the future"
> Thinking about that... What I'd really like to > see is for MS to provide a full set of COM interfaces > to .Net. Then it would be scriptable. We're in a funny > in-between place now. Windows is COM and looks like > it will be for the foreseeable future, yet MS is moving > .Net right into Windows by doing things like adding > .Net support to PowerShell. So it'd be nice if they'd > take it full circle and incorporate .Net fully with COM.
Wouldn't that be an admission they were wrong to excise VB6 from the pathway?
> > Thinking about that... What I'd really like to > > see is for MS to provide a full set of COM interfaces > > to .Net. Then it would be scriptable. We're in a funny > > in-between place now. Windows is COM and looks like > > it will be for the foreseeable future, yet MS is moving > > .Net right into Windows by doing things like adding > > .Net support to PowerShell. So it'd be nice if they'd > > take it full circle and incorporate .Net fully with COM.
> Wouldn't that be an admission they were wrong to > excise VB6 from the > pathway?
Were they wrong? I'm not one of the people who feels betrayed by the ending of VB. I find .Net irrelevant, and Microsoft's attempt to turn Windows into a locked down services appliance is sad, misguided and deplorable to my mind. I think they're wrong to focus so single-mindedly on profits rather than product.
But it's their business, after all. I'm looking at it from my personal point of view: I love Windows. I love Windows programming. I'd like to keep using Windows until it just becomes too unpleasant to do so. (I haven't decided what I'll do when the time comes that I finally have to choose whether to use Microsoft's Product Activation-ed spyware. :)
.Net is looking a lot like the next ActiveX to me. By trying to have ActiveX do all things well they end up with a product that does most things poorly: ActiveX is unsafe online but not well suited for Windows software. (For some of the same reasons that .Net isn't. It's slow, bloated, unnecessary wrappers with extra dependencies.)
Now MS is taking the same path with .Net, trying to get online leverage by tying .Net deeply into Windows, while also pushing .Net as a competitor to Flash/AIR, and also still pushing it as a Java competitor.
So they end up with something that's poorly suited for Windows software, risky for online due to being tied into Windows, and iffy as a true Java replacement due to the fact that "managed code" is only an option. There's no enforced sandboxing.
Given all of that, I see .Net as like ActiveX. I wouldn't use it online. I wouldn't run software that uses it online. And I avoid it for Windows software. But it sure would be a handy-dandy addition to the scripting toolbox, if only they'd add Dispatch interfaces. :)
Though of course there's still Al's point -- the 88-200+ MB runtime must be installed. That's not a problem that ActiveX has. But a scriptable .Net would be a fullscale, scriptable programming environment.
Nearby, there is a newsgroup provided for the benefit of vb "classic" (vb5/6) coders. In recent years the activity there has declined, to the point where there are now just a few groupies left. They are loyal to their vb.classic product, to the extent that they defiantly assert that it is superior the the latest microsoft product -- vb.net.
Occasionally, through either misunderstanding or ignorance, a vb.netter will post a question in the vb.classic ng. The vb.classicos will politely refer them to an ng with "net" in the title (such as: vb.net or net framework).
However, I have never seen a vb.netter come over to the vb.classic ng and suggest that the vb.classicos ought to give up vb.classic because it is old and obsolete.
> However, I have never seen a vb.netter come over to the > vb.classic ng and suggest that the vb.classicos ought to > give up vb.classic because it is old and obsolete.
You haven't been around enough, then. :) There are at least 4 regular proselytizers who hang around the VB group only to talk up .Net. Actually it seems like a very similar situation to scripting: Microsoft has created two completely different tools but they have their own reasons to steer people toward one and away from the other. And it's human nature to want to be on the winning team, using the fashionable tool, etc. So it doesn't take long for Microsoft's marketing efforts to become the common wisdom, with people no longer even thinking about how or why they arrived at the opinion they hold.
> acomputerwiz6 wrote: >> powershell is the future.
> Nearby, there is a newsgroup provided for the benefit > of vb "classic" (vb5/6) coders. In recent years the > activity there has declined, to the point where there > are now just a few groupies left. They are loyal to > their vb.classic product, to the extent that they > defiantly assert that it is superior the the latest > microsoft product -- vb.net.
> Occasionally, through either misunderstanding or ignorance, > a vb.netter will post a question in the vb.classic ng. The > vb.classicos will politely refer them to an ng with "net"
I guess you haven't been to microsoft.public.vb.general.discussion for a while.
The reminders are sometimes less than polite.
> in the title (such as: vb.net or net framework).
> However, I have never seen a vb.netter come over to the > vb.classic ng and suggest that the vb.classicos ought to > give up vb.classic because it is old and obsolete.
As above, I would say you haven't visited lately as there is a pretty steady stream of DotNetters preaching the Gospel of managed code, provoking some less than inspiring exchanges between the two visages....
>> Nearby, there is a newsgroup provided for the benefit >> of vb "classic" (vb5/6) coders. In recent years the >> activity there has declined, to the point where there >> are now just a few groupies left. They are loyal to >> their vb.classic product, to the extent that they >> defiantly assert that it is superior the the latest >> microsoft product -- vb.net.
>> Occasionally, through either misunderstanding or ignorance, >> a vb.netter will post a question in the vb.classic ng. The >> vb.classicos will politely refer them to an ng with "net"
> I guess you haven't been to microsoft.public.vb.general.discussion for a > while.
> The reminders are sometimes less than polite.
>> in the title (such as: vb.net or net framework).
>> However, I have never seen a vb.netter come over to the >> vb.classic ng and suggest that the vb.classicos ought to >> give up vb.classic because it is old and obsolete.
> As above, I would say you haven't visited lately as there is a pretty > steady stream of DotNetters preaching the Gospel of managed code, > provoking some less than inspiring exchanges between the two visages....
>> cheers, jw
Interesting comments all round.
You might have gotten the impression I am pro-PS and anti-VBS, but that's not really the case. I have a soft-spot for VBS, but have not done much scripting of late. That said, I would not necessarily take a pro-VBS/anti-PS stance when talking to someone new to both. Powershell seems to be the future, unless enough vbs die-hards wield enough influence to resist MS' current directions.
>>> Nearby, there is a newsgroup provided for the benefit >>> of vb "classic" (vb5/6) coders. In recent years the >>> activity there has declined, to the point where there >>> are now just a few groupies left. They are loyal to >>> their vb.classic product, to the extent that they >>> defiantly assert that it is superior the the latest >>> microsoft product -- vb.net.
>>> Occasionally, through either misunderstanding or ignorance, >>> a vb.netter will post a question in the vb.classic ng. The >>> vb.classicos will politely refer them to an ng with "net"
>> I guess you haven't been to microsoft.public.vb.general.discussion for a >> while.
>> The reminders are sometimes less than polite.
>>> in the title (such as: vb.net or net framework).
>>> However, I have never seen a vb.netter come over to the >>> vb.classic ng and suggest that the vb.classicos ought to >>> give up vb.classic because it is old and obsolete.
>> As above, I would say you haven't visited lately as there is a pretty >> steady stream of DotNetters preaching the Gospel of managed code, >> provoking some less than inspiring exchanges between the two visages....
>>> cheers, jw
> Interesting comments all round.
> You might have gotten the impression I am pro-PS and anti-VBS, but that's > not really the case. I have a soft-spot for VBS, but have not done much > scripting of late. That said, I would not necessarily take a > pro-VBS/anti-PS stance when talking to someone new to both. Powershell > seems to be the future, unless enough vbs die-hards wield enough influence > to resist MS' current directions.
The evidence of the VB6 world's treatment by MS would fairly conclude that "Resistance Is Futile". For myself, I have a neutral stance with regard to VBS/PowerShell. I don't use PS, but wouldn't be adverse should the need arise. At this late stage of my game, I have precious few bits of grey matter to spare needlessly.. ;-)
As in my earlier post, powershell is the 'future' but I also see it as a successor to batch file style scripting. I still use vbs and hta's heavily. I think you should use the tool best suited for the task at hand. I don't think powershell replaces vbscript, as long as Microsoft continues to support it natively within the operating system.
>>>> Nearby, there is a newsgroup provided for the benefit >>>> of vb "classic" (vb5/6) coders. In recent years the >>>> activity there has declined, to the point where there >>>> are now just a few groupies left. They are loyal to >>>> their vb.classic product, to the extent that they >>>> defiantly assert that it is superior the the latest >>>> microsoft product -- vb.net.
>>>> Occasionally, through either misunderstanding or ignorance, >>>> a vb.netter will post a question in the vb.classic ng. The >>>> vb.classicos will politely refer them to an ng with "net"
>>> I guess you haven't been to microsoft.public.vb.general.discussion for a >>> while.
>>> The reminders are sometimes less than polite.
>>>> in the title (such as: vb.net or net framework).
>>>> However, I have never seen a vb.netter come over to the >>>> vb.classic ng and suggest that the vb.classicos ought to >>>> give up vb.classic because it is old and obsolete.
>>> As above, I would say you haven't visited lately as there is a pretty >>> steady stream of DotNetters preaching the Gospel of managed code, >>> provoking some less than inspiring exchanges between the two visages....
>>>> cheers, jw
>> Interesting comments all round.
>> You might have gotten the impression I am pro-PS and anti-VBS, but that's >> not really the case. I have a soft-spot for VBS, but have not done much >> scripting of late. That said, I would not necessarily take a >> pro-VBS/anti-PS stance when talking to someone new to both. Powershell >> seems to be the future, unless enough vbs die-hards wield enough >> influence to resist MS' current directions.
> The evidence of the VB6 world's treatment by MS would fairly conclude > that "Resistance Is Futile". For myself, I have a neutral stance with > regard to VBS/PowerShell. I don't use PS, but wouldn't be adverse should > the need arise. At this late stage of my game, I have precious few bits > of grey matter to spare needlessly.. ;-)
> As in my earlier post, powershell is the 'future' but I also see it as > a successor to batch file style scripting.
Mostly true, however, it is so much farther advanced that it opens up areas of application that are well outside of batch's native capabilities.
> I still use vbs and hta's > heavily. I think you should use the tool best suited for the task at > hand.
Exactly.
> I don't think powershell replaces vbscript, as long as > Microsoft continues to support it natively within the operating system.
I don't think that MS would consider vbscript (a language that operates in a variety of environments, including one, WSH, that tags along with the more recent versions of windows) as in any way equivalent or comparable to powershell, which is not only the language but uts implementation. They would more likely consider WSH itself as being more of a product that the new product could consider to replace.
That said, powershell hasn't actually replaced either batch or WSH, in that both are still present and, to some degree, supported. But the writing is definitely on the wall, and has been for some time, that both of the two older environments have at their evolutionary dead ends. Batch in vista and windows 7 may include more functionality than in XP, but I suspect that is mostly provided by a new set of executables rather than any further enhancement of its syntax and built-in functionality. As for WSH, even though a newer version came out a while back (5.7) I think that was just to give it a bit more time. I don't believe that that version addressed any of the bugs we have known about for a long time now.
So when we say ps is the future, we are not necessarily predicting a complete demise for WSH, just acknowledging that its future evolution is not as assured.
Special Access wrote: > I am looking for an IDE for vbscript
Here's my 2 cents.
If you have an unlimited software budget: PrimalScript.
If you have ms office installed, then the "microsoft script editor" is serviceable. Look for MSE.EXE or MSE7.EXE. (Or maybe MSE+some number higher than 7). Anyway, MSE can be used to debug standalone scripts, but not "as is". Look in the archives of this ng to find the "tips" explaining what you need to do.
From a broader perspective, the notion of a scripting IDE sounds a little off-base to me, because I am oriented to the vb IDE. With vb, the IDE is used chiefly for keeping track of your project's program modules, and for constructing GUI's (vb Forms), as well as debugging. When developing scripts, a text editor and a "run" command is sufficient for me. I run the script until it stops producing errors, and then consider myself done. (All you Quality Control Engineers kindly constrain your urge to vomit).
With that preamble, I would like to suggest the scintilla test editor control (with syntax high-lighting), and its accompanying SCITE text editor. Scintilla is highly competent and efficient, and is used as a basis for a number of editors for specific languages (Autoit, FBSL, BCX (the Basic-to-C-Language translator), Emergence Basic, Programmers Notepad, and others).
The SCITE text editor contains a "lexer" for vb, and can easily be modified for vbscript.
The point here is that scintilla and SCITE are all open source. You can use it as a basis for developing your own IDE, with all the features you want.
Finally, you can use vb (classic), i.e., vb5/6, as a vbScript IDE. Even if you don't have vb5/6, there is a (free) version of vb5, called vb5 Control Creation Edition (vb5cce) around. Although microsoft has dropped the download page, there are still a couple of other places around the internet where it can be found.
With vb (classic), you just write your code into a bas module with a "Sub Main", declare all your variables to be variants, and away you go...
You got questions? WE GOT ANSWERS!!! ..(but, no guarantee the answers will be applicable to the questions)
p.s. Still using win98 and interested in scintilla? Then you are going to have to search back, to get version 1.75, dated Nov 22, 2007. After that, the developers dropped support for win98.
|
