GEEK I got so excited about the new Visual Basic® WebClass technology that I incorporated my existing site's HTML files into the Microsoft® Internet Information Server (IIS) application project. Everything works great when I run it on my development computer, but when I transfer it to my Internet server I get a bunch of error messages. My ISP doesn't have Visual Studio® 6.0 installed, so I can't use the Posting Acceptor on that end. Is there an easier way to deploy WebClass apps than through PDW? GEEK To support and deploy the WebClass technology properly, you need to get the proper support from your ISP. They need to be running Windows NT® Server, have IIS enabled, and have the proper Visual Studio server-side services installed, including Posting Acceptor 2.0. In your case, Posting Acceptor 2.0 must run on the server to allow deployment of server-side objects. You should contact your ISP and see if they are willing to add this support.       Your situation is comparable to someone who wants to watch the TV show South Park but can't because their cable provider doesn't carry Comedy Central. Where I live, the cable service provider doesn't carry Comedy Central, which means if I want to watch South Park I have to switch service providers (by getting a satellite dish) or move to another area where Comedy Central is offered. There isn't any way to install Comedy Central onto the offerings provided by my cable service provider. They have to be the ones to set this up and offer me this service. (Note: geektogeek does not condone the killing of Kenny.) GEEK How do you provide background MIDI music on a Web page so it works with all versions of Microsoft Internet Explorer and Netscape browsers? I tried using the script in Figure 1, which works in Internet Explorer (and with Netscape browsers when run from my local hard drive), but doesn't work with Netscape software when run over the Web. GEEK As regular readers of my column know by now, adding background sounds to Web pages is not one of my favorite pastimes. Therefore, I don't spend too much brain power trying to figure out how to do it on as many different browsers as possible.       That said, I think you are being far more robust than you need to be. While your code appears to work fine on Internet Explorer versions 3.0 through 5.0 and on Netscape Navigator 4.0, the following code is a lot shorter, and appears to work just as well:

<embed src="PathToMusic.mid" autostart="true" hidden="true" loop="1" controls="smallconsole"> <bgsound src="PathToMusic.mid"> </embed>

Note that no version of Navigator supports the <bgsound> tag. Therefore, it is perfectly safe to simply use it; if it works, it works, and if it's ignored, it doesn't work. By placing the <bgsound> tag inside the <embed> container, <bgsound> won't be launched unless the <embed> tag fails due to a lack of embeddable apps associated with the MID extension. So if there is a properly registered player for .mid files on your system for the browser you are using, this should work in all cases. But, of course, you can simply not play the sound, and your problem will be solved! GEEK I want to create an input box that will display the amount of time remaining in an online test. I am using the window.setTimeout function to call a procedure that will decrement the time remaining every second. I want to do this on the client's machine, but initially I need to use the server's time to calculate the countdown start point. Rather than depend on the client's time, I want to use the server's system time. How do I pass the server's current system time to client-side JScript®? <%=Time()%> doesn't work inside a <SCRIPT> tag. GEEK If you really want to have a client-side script variable with the server's current time in it, then the most accurate way to do this is to write an ActiveX® control or a Java applet to open up a communication pipe back to the server, then use this pipe to obtain the time. You would then need to do some special calculations to determine the round-trip delay between client and server, and use this to modify the received time value to get as close an approximation as possible to what the actual time is on the server.       But I don't think this is what you really need to do in your situation. As I understand it, you simply want to provide a countdown timer on the client for an online test. You say that you want to use the server's time to initialize this, since you don't want to be dependent on the client's time. Frankly, I can't think of a single reason why the client's time should be a problem.       While it is almost certain that the client system's clock isn't set to the exact same time as the server (and it is easily conceivable that the client's clock could be off by a tremendous amount) this wouldn't affect a countdown timer at all. So simply starting the countdown based on the client system's clock shouldn't be a concern.       However, let's say that there really is some reason that you need to get the server's time into a client-side script variable. Although you say that simply using <%=Time()%> within a <script> tag doesn't work, the following code works just fine for me:

<html><body> <script language="javascript"> t = "<%=Time()%>"; document.write (t); </script> </body></html>

What might be confusing is that the output of <%= Time()%> is a string value that represents the current time and not a numerical value. Therefore, you need to convert this string value back into a valid time value if you want to use it that way. GEEK Can you tell me what versions of the following software are Y2K-compliant: Windows® 3.1, Microsoft Visual C++® compiler, Visual Basic, and Windows NT? GEEK The best place to get information on the Year 2000 in relation to various Microsoft products is http://www.microsoft.com/y2k. There you can view information about Y2K and how Microsoft is addressing these issues. This Web site also has a link to a database of tested products.       And while I'm on the subject of Y2K: one of my pet peeves is referring to this as the Millennium Bug, which implies that this is a problem that only occurs at the turn of a millennium. In fact, it is only by coincidence that we are encountering this situation at the turn of a millennium. If computers had been around in the 1800s, the same situation would have been encountered when the year flipped over to 1900. So the proper name for this problem is really the Century Bug.

From the February 1999 issue of Microsoft Internet Developer.