Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ VBscript
➜ VBScript (HTML) vs VBScript (MUSHclient)
|
VBScript (HTML) vs VBScript (MUSHclient)
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Xyborg
Canada (47 posts) Bio
|
| Date
| Thu 16 Oct 2003 08:05 PM (UTC) |
| Message
| Is it the EXACT same thing or are the some differences between the two?
Just need to know because I'm learning VBScript for webpages and I'm picking up on it rather well and I was hoping that what I'm learning is exactly the same as what's used in MUSHclient. |
We offer power to those willing to take it. Sadly, few are unburdened enough by their prejudices to accept. | | Top |
|
| Posted by
| Dubthach
(47 posts) Bio
|
| Date
| Reply #1 on Thu 16 Oct 2003 08:41 PM (UTC) |
| Message
| | They're exactly the same thing. Just make sure you understand the difference between VBScript the language and the DOM. You obviously won't be interacting with the DOM when you use VBScript through MushClient. | | Top |
|
| Posted by
| Shadowfyr
USA (1,792 posts) Bio
|
| Date
| Reply #2 on Thu 16 Oct 2003 08:57 PM (UTC) Amended on Thu 16 Oct 2003 08:58 PM (UTC) by Shadowfyr
|
| Message
| Umm.. Yes and no. lol
The main differences are fairly obvious.
1. Things that require IE's method of using objects by specifying the CLSID won't work. This is not really a script 'feature', but an IE one that no one else uses, let alone supports. The same rule applies to the hand full of other methods that exist in browsers to use such things. As a result any such object needs to be created using CreateObject, which you almost never see used in web pages or even very often in full VB apps.
2. Things like this:
are a major no-no. In a browser the script runs parallel with the browser, so you can infinite loop things and perform other type of activities and the browser will usually keep working. In Mushclient trying to do something like that will hang the client and force you to use Ctrl-Alt-Del to get out of the situation. Unless the loop is short and simply does something, then exits, you have to code things so that you call them over and over to perform the task instead. In the case of the above, you would use a timer to call the code over and over forever, rather than looping it. Same is true of delays that are intended to make something 'pause' for a certain time before taking action. Anything that prevents the code from exiting will prevent Mushclient from regaining control and functioning.
3. Forget about any fancy tricks that use text boxes or other 'built-in' features that are common to browsers. With the exeption of the MessageBox and alerts, which are built into the script, these things don't exist in Mushclient.
4. Things that the script does in Mushclient won't happen until 'after' the script has exited (this is the non-parallel issue again). In other clients and in browsers, a second script could begin responding to the results of a command sent by the first script or some other event, even before the first script finishes. With Mushclient you have to keep track of everything you want done 'after' all the events have been dealt with, before you can post output or expect the client to respond to certain results or the commands your script sent. Example"
send "Stats sword"
setvariable "sw_str",""
setvariable "sw_type",""
...
There may be legitimate case in HTML where this 'can' work and it apparently will in some other clients. I can't see how without risking lag eating the results, but it apparently can and does. If you are in the habit of expecting this to work, break the habit now. It is imho a bad practice, even if it can work in some clients or on a web page (the later of which I am not sure about).
Can't think of any more glaring differences right now. It is definitely different in the sense that it won't work 'quite' the same way as a web page may. In terms of if it is identical in terms of the code itself and how vbscript works in general, then it is identical, since it uses the same engine to run it. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #3 on Thu 16 Oct 2003 10:10 PM (UTC) |
| Message
| VBScript is the same no matter where you use it. What changes is the surrounding "API calls" (to MUSHclient functions, or to IE functions, or whatever environment is calling the script.) What also changes is the mechanism in which the script is run, i.e. when control is passed back and forth, etc. This is all, however, completely dependent on whatever is calling the script.
So basically, VBScript (or any other scripting language, such as Javascript or Perlscript) will have the same syntax and mostly the same behavior, but any functions that aren't built in to the language (i.e. accessing the world entity in MUSHclient, or some internet thing in IE) will most likely no longer function - unless the environments each implement their own version of the function, independent from the core set of built-ins.
It's actually a lot like normal programs and the OS they run in. A C program will function more or less the same everywhere, unless you use OS-specific behavior (for example, Windows API calls.) The OS also determines which programs are run when. So while it's not exactly the same situation for scripts, it's quite similar. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Sat 18 Oct 2003 10:40 PM (UTC) |
| Message
|
Quote:
Things that the script does in Mushclient won't happen until 'after' the script has exited (this is the non-parallel issue again). In other clients and in browsers, a second script could begin responding to the results of a command sent by the first script or some other event, even before the first script finishes.
Most things happen immediately, however you can't do (say) "send <something>" and hope to get a response immediately. This is because the send itself may be queued, and the response may not arrive for a few seconds. Thus in that sort of situation you would set up a trigger to handle the response.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
19,703 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top