The ID of the weather server appears to be wrong

[Paul Howard]

Hi,

I'm working on a weather server. I've created the .wsc file using one of the existing .wsc files as a basis. I've successfully registered it with regsrv32 (with it's own unique class id). I don't seem to be able to figure out the correct weather server object id in ACPs preference dialog for weather. Where is the weather server object id defined in the .wsc file? I've tried every string I can think of from my .wsc file and none of them seem to work.

Thanx,

Paul Howard

[Bob Denny]

It's what you put into the progid.

        <?component error="false" debug="false" ?>
        <registration progid="Xyzzy.Weather" classid="{0C65384D-4054-4745-B224-BCF9A39A4F8A}" description="ACP weather server for Xyzzy" remotable="no" version="1.0">
        </registration>

Be sure to use a GUID generator to make a unique classid.

Maybe you registered it for 64 bit (right-click register)? Instead start C:\Windows\Syswow64\CMD.exe as administrator (right click run as administrator) then use that to register it

cd "C:\Program Files (x86)\ACP Obs Control\WeatherComponents"
regsvr32 MyServer.wsc

Now it should be visible

[Paul Howard]

Hi Bob,

Thanx. That's what I tried.

<component id="WeatherUnderground">
<?component error="true" debug="false" ?>
<registration progid="WeatherUnderground.Weather" classid="{081998e4-9029-4bc0-940f-525764f66b7d}" description="ACP weather server for Weather Underground" remotable="no" version="1.0">
</registration>

Used WeatherUnderground.Weather in the ACP pref dialog. I had initially registered with right click register, but that didn't work. So I went to the command line as admin and used regsvr32 and it succeeded. I also looked at the registry entry for the class id and it appeared to be correct.

Any ideas on where to look at this point? Does the script auto-start when ACP tries to connect or does it need to be started by another mechanism?

Thanx,

Paul

[Bob Denny]

So you put WeatherUnderground.Weather in ACP's Weather Server ID? Check the Spelling.

ACP will start calling your server when you connect weather. One way to check it is to implement something in the SetupDialog() method. In ACP Preferences, Weather tab, click Setup Weather. This will call your SetupDialog() method (no parameters). The name of your server is intriguing!!! And you have error="true" which will pop up errors, but you can have debug="true" and install the Microsoft Script Debugger (in ProgFiles\ACP\ScriptING), or the full Visual Studio has a great script debugging facility. You'll need to check the "enter debugger" option in ACP Preferences, Debugging too. Now put a Stop statement (VBScript) or debugger; statement (JScript) and it will jump into the debugger at that point.

[Paul Howard]

Hi Bob,

So I installed the Microsoft Script Debugger, set debug to true in the script, turned on the enter debugger option in ACP, and tried again (copy and paste the ID). Same message (ID appears to be wrong) and no entry into the debugger. Then I tried WeatherAccess.wsc (registered it, set the ACP weather option to it's id) and the same message. So then I tried BoltwoodFile.wsc and I got the file system dialog popup for the clarity log file. Modified BoltwoodFile.wsc to turn on debug and put a stop as the first statement in SetupDialog. Tried again and it popped up in the script debugger on the stop. Went back to both WeatherAccess.wsc and my WeatherUnderground.wsc put the stop into SetupDialog and tried them as the ACP weather server. Same message (ID appears to be wrong) and NO entry into the debugger so it looks like it doesn't even get to SetupDialog. I've looked carefully at the registry entries for the BoltwoodFile and the other weather servers. Only differences are those I expected (e.g. scriptUrl changes for the correct .wsc file, but the path is the same).

Any thoughts?

fyi - Yes, this is a weather server using the weather underground api's. It's been running standalone for a week or so now and appears to be fine. So hopefully, it's just getting past the ACP / weather server integration. Rotating list of multiple wu stations (including allowing weighting - my test uses a rotation of "local", "nearest east", "local", "nearest north", "local", "nearest west", "local", "nearest south" - so my local station has 4 times the weight of the adj stations), configurable limits on each of the weather values (current, average, maximum) used in the safe/unsafe calc. Uses wind speed, wind gust, precip last hour, prob of precip next hour, weather state (clear, partly cloudy, etc.), cloud coverage next hour, humidity - configurable to ignore any of these. Limits wu api usage to avoid exceeding the limits on their api - polls starting a configurable plus/minus from sunset, stops polling a configurable plus/minus from sunrise, restricts polling to a configurable frequency.

Paul

[Bob Denny]

So you know that the COM system in Windows is working (BoltwoodFile is OK) and that a server that is already registered on ACP installation (BoltwoodFile) works as advertised, and that my instructions for trapping into the debugger are correct. That (seemingly) leaves only your process for registering the WSCs.

Again... navigate to C:\Windows\SYSWOW64\CMD.exe and right click, Run as... Administrator. When the window appears

> CD "C:\Program Files (x86)\ACP Obs Control\WeatherComponents" (or wherever your weather server WSC is, it doesn't really matter)
> regsvr32 WeatherUndergroundWeather.wsc (or whatever its file name is)

You need to see a "success" popup.

[Paul Howard]

Hi Bob,

Well my mistake. Who would of thought Microsoft would have put two different administrative command lines in the system. And that only one of them would properly run regsvr32. I had done all you indicated in your last reply and gotten the success popup - but with the other administrative command line. As soon as I used the SYSWOW64 administrative command line things started working. The odd thing is I can't see any difference in the registry entries for the class id between the using the other administrative command line and the SYSWOW64 version.

So it is up and running now. btw - I notice you poll get_Safe() once per second. Is there a particular reason behind using such a high frequency?

Thanx again for your help.

Paul

[Bob Denny]

The difference is in the "bitness" 32 vs 64. These are two separate environments in Windows 64 systems. There is admin in 64 and admin in 32. Write Steve Ballmer about the name SYSWOW64 being for 32 (joking, he is relaxing in Tahiti, gone from MS). It means Windows on Windows 64. Go figure.

[Bob Denny]

Oh, and yes, the rapid poll is to protect the observatory. It takes time to close up so I want it to be really responsive. It's a cheap poll... Or it should be. Your driver or server is responsible for protecting against what client calls that are too fast for the hardware.

[Bob Denny]

What is the status on this old issue? I am trying to clean out my queue.