I take it back, this does not seem to be an SGPro issue. In this case, the Pegasus driver is presenting that message box. In general, drivers should never attempt to control or alter the user interface unless it is expected as part of a contract (e.g. settings dialogs, etc)… especially if it blocks further execution of the consuming application (this type of message box does block). It seems like the root of the problem is that the driver does not tell SGPro that there was a problem connecting, but rather indicates the connection went fine and then, afterward, not as part of the communication to establish the connection, pops this error up, despite never actually being connected. Instead of “polling” for a lost connection or other error state, ASCOM drivers should just alter internal state to reflect the issue and then, when an action is requested that, due to the error state, cannot be fulfilled, an exception should be raised and place the burden of communication on the client application (SGPro) (i.e. drivers should behave in a transactional way). SGPro asks for something and the driver either handles it or says why it can’t, but does not attempt to communicate in an unsolicited manner.