|
|
|
|
Group: Forum Members
Last Login: Wednesday, September 07, 2011
Posts: 12,
Visits: 22
|
The Connected property is not synchronous with the Connected-Event and the getConnectionState code. It seems that is is already set to true, when the getConnectionState begins "CONNECTING".
I think it should be: getConnectionState=CONNECTED if only if connected=true.
|
|
|
|
|
Group: Administrators
Last Login: 10 hours ago
Posts: 1,625,
Visits: 3,045
|
You are correct get_Connected may return TRUE even if the Connected even hasn't been fired yet. It's not really a bug, its by design as it stands now.Internally get_Connected public property is implemented like this: STDMETHODIMP CSC_ViewerXControl::get_Connected(VARIANT_BOOL* pbConnected)
{
if (!pbConnected)
RETURN_EI_ERROR(E_POINTER); VncConnectionState state;
GetConnectionState(&state); *pbConnected = state != VCS_DISCONNECTED; return S_OK;
} So it will return TRUE even if ViewerX is in process of establishing a network connection. GetConnectionState is the method to use if you want to get more precise information about the connection status. But may I ask you why would you need this? Why simply not listen for Conncted Disconnected events?
We are looking for investors and business partners. Please contact us for more details
Kindest Regards,
SmartCode Solutions Support
|
|
|
|
|
Group: Forum Members
Last Login: Wednesday, September 07, 2011
Posts: 12,
Visits: 22
|
Menu points like "Send-Ctrl-Alt-Delete" were enabled based on the value of the Connected property, and I was wondering, why I the items get enabled to early and cause errors when selected during the connecting state.
I could now switch to getConnectionState method, but I also think the Connected should be changed to be only true, when the control it is really connected not during the connection state. That would be consistent with getConnectionState and the connected properties. Also this is the most commonly needed state: Either you are fully connnected or not. The intermittend "connecting" state is not interesting on most cases.
If one really wants to check for "connecting", there is the finer grained getConnectionState
|
|
|
|
|
Group: Administrators
Last Login: 10 hours ago
Posts: 1,625,
Visits: 3,045
|
Menu points like "Send-Ctrl-Alt-Delete" were enabled based on the value of the Connected property, and I was wondering, why I the items get enabled to early and cause errors when selected during the connecting state.
Actually it would be a good idea to have them disabled by default. This is more logical. You are starting with a disconnected control, so GUI items like Send CAD, File-Transfers, etc should be disabled initially. They should get enabled only in case if the Connected event has been raised.The intermittend "connecting" state is not interesting on most cases.
That's exactly the point! Imagine that GetConnectionState doesn't exist at all and you are developing a GUI application using ViewerX. And you have to enable a "Connet to XXX" button in your application based on the ViewerX "Connected" property value. With the current ViewerX implementation the button will be enabled if ViewerX is disconnected and disabled if ViewerX is already connected or establishing a connection.But if we change the property behavior the way you propose, the imaginable "Connect to XXX" button will be enabled even if ViewerX is in process of establishing a connection. And the next thing that will happen is that your end-user will start complaining about inconsistent enabled/disabled state of the "Connect to XXX" button.
We are looking for investors and business partners. Please contact us for more details
Kindest Regards,
SmartCode Solutions Support
|