Perhaps Chris R can comment on this but I believe drivers written to the V2 ASCOM spec may not be bound to using the same set of exception code numbers as are currently used by ASCOM. The ASCOM Telescope V2.0 Programmers reference (Jan 16 2008) only specifies the base address for exceptions (0x80040400) and no others. The ASCOM telescope simulator source from that era has a few more error codes defined but they do not match, and some conflict, with those currently specified by ASCOM.
EQMOD is a V2 driver but for its next release I will make sure it is using the current (V3?) ASCOM exception codes.
This is going to take more thinking and experimenting.
The InvalidOperationException is a .NET exception and EQMOD is a VB6 application so will have difficulty throwing a .NET exception. It will, I think, throw a COMException with an error number that identifies the error.
/// Error code to indicate that the requested operation can not be undertaken at this time.
public static readonly int InvalidOperationException = unchecked((int) 0x8004040B);
I think this means that in addition to catching the InvalidOperationException COMException also needs to be caught and the ErrorCode checked.
I’m going to update the .NET telescope simulator so it can throw the InvalidOperationException for a sync when the position is past the meridian.
Yes, I’d already discovered the ErrorCodes.cs source and this was when I noticed that the COMException codes used in the earlier VB6 sample and driver code that ASCOM provided do not match exactly the equivalent codes now used in the ErrorCodes.cs. For a .Net based driver the error handling is clearly defined, but for an older COM based driver the error codes may be less predictable - unfortunately client applications need to support both unless ASCOM want to cut all VB6 drivers completely (which I suspect would be the end of EQMOD). Hopefully I’ve done the correct thing in now aligning EQMOD’s COM exceptions with the .Net ones.
The way I am reading this is that SGPro can just continue catching InvalidOperationException because @Chris_Shillito is matching / mimicking (modern) .NET error types. If I’m reading this wrong or we need to do something else, we can probably do that. Just let us know…
I can also provide test builds if they of any use to anyone…
As I said in my previous reply EQMOD is a VB6 application and so can’t raise .NET exceptions. It will raise a COM exception with a message string and an error code. This will, I believe, be translated to a .NET COMException and thrown as such.
This means that SGP should catch two errors, the ASCOM.InvalidOperationError and the COMException. In the case of COMException it should check the ErrorCode.
I would still remove the Sync entirely from the meridian flip code. It doesn’t achieve anything the user needs. You still acquire an image and plate solve it because this provides the target for the centre process after the flip. It would even save time because the flip slew could be started as soon as the image had been acquired and the solve would be done while the mount was slewing.
For EQMOD I will provide a COMException to report an InvalidOperationError using the error code 0x8004040B - however I suspect that EQMOD may be the only driver doing this and other drivers may well apply their own “unique” sets of errors codes (the meade driver for instance uses 0x8004040B to report a “below the horizon” specific failure)
So it maybe that a more generic/pragmatic solution is simply to trap the COMException and, irrespective of the associated error number, just take this as an indication that the requested function has failed.
Maybe. Right now it has everything a user doesn’t need… the chance of major regression and us not having the time to fix it. While I’m not ruling anything out, we are not looking for any major workflow or UI changes at the moment.
I have added the COM exception to sync… this will also not cause the underlying process to fail.