09-15-2004, 06:39 PM
09-15-2004, 07:30 PM
I don't know how to, but I'm almost positive you can
09-16-2004, 01:54 AM
There is no possibility of getting direct hardware access with VBS.
Not with VBS alone, at least. You could still write a program that can access the ports and let your VBScript communicate with it somehow. (Eg. execute it from the VBScript and pass it command line parameters.)
Which is no problem under Win98. Under Win2k/XP you would have to use something like WinIO to get access to the ports.
Not with VBS alone, at least. You could still write a program that can access the ports and let your VBScript communicate with it somehow. (Eg. execute it from the VBScript and pass it command line parameters.)
Which is no problem under Win98. Under Win2k/XP you would have to use something like WinIO to get access to the ports.
09-16-2004, 12:16 PM
For what I have read i could use an ActiveX control to access the port. The problem is most serial port ActiveX have clear instructions for VB, VC or Delphi where you can open control's properties in the IDE, but say nothing about VBS...
09-18-2004, 04:16 AM
Just happened to troll by here and see this thread.
I've done a fair bit of stuff with the MS Comm 32 Control inside VB6. (It was an application to talk to a seral port-based interface box)
I doubt if VBS can touch that stuff (primarily for security reasons, but you can definitely do it from VB)
I've done a fair bit of stuff with the MS Comm 32 Control inside VB6. (It was an application to talk to a seral port-based interface box)
I doubt if VBS can touch that stuff (primarily for security reasons, but you can definitely do it from VB)
10-03-2004, 11:52 PM
The biggest problem with using the MS Comm 32 Control from VBScript is probably going to be licensing. If you can get it working, it'll only run on a machine with VB installed. I'm assuming you are talking about a WSH script when I say this. WSH doesn't have a mechanism to incorporate a run-time license for a licensed control, so it'll only run where you have a developer license (installed when VB is installed).
You can probably create an unlicensed wrapper control in VB though.
Another possibility is to create an HTA instead of a WSH script. HTAs are IE-based DHTML applications, and can use the ActiveX control licensing features of IE. You'd need to use LPKTOOL.EXE to create the license package.
Here's a skeletal usage sample I grabbed out of my local copy of MSDN Library, this one for the UpDown Control:
The Updown.lpk file references is the license package file created via LPKTOOL. I'd use a local copy of ComCt232.cab and deploy it with my HTA though, since access to activex.micrsoft.com requires an Internet connection. This example was really meant for a web page, but an HTA is basically identical - with your script inside <SCRIPT> blocks.
A third-party ActiveX control is the final alternative I can think of. An unlicensed control would be best for WSH scripts.
You can probably create an unlicensed wrapper control in VB though.
Another possibility is to create an HTA instead of a WSH script. HTAs are IE-based DHTML applications, and can use the ActiveX control licensing features of IE. You'd need to use LPKTOOL.EXE to create the license package.
Here's a skeletal usage sample I grabbed out of my local copy of MSDN Library, this one for the UpDown Control:
Code:
<HTML>
<BODY>
<!-- License Class Manager
<OBJECT CLASSID="clsid:5220CB21-C88D-11cf-B347-00AA00A28331">
<PARAM NAME="LPKPath" VALUE="Updown.lpk">
</OBJECT>
<!-- Licensed Control
<OBJECT classid="clsid:026371C0-1B7C-11CF-9D53-00AA003C9CB6" id=UpDown1
codebase="http://activex.microsoft.com/controls/vb6/ComCt232.cab">
</OBJECT>
</BODY>
</HTML>A third-party ActiveX control is the final alternative I can think of. An unlicensed control would be best for WSH scripts.