Regarding #1 - Sorry, I think I used the wrong term. I meant two Monitors. It seems to start with dual monitor view, and switch to #1. This takes time on a slow connection, and possibly can be avoided?
Ok, no problem. Actually, your monitor selection should be remembered for this connection so the next time you start it it should immediately show you the selected monitor. Is that the case?
Can you explain the way you currently implement the auto-reconnect (using IP? Using ID?)
Auto-reconnect is just what it is - the program attempts to re-connect to a remote computer if there is brief network interruption, usually a few seconds long or more (i.e. noticeable by human).
and how to make it always check for correct IP by ID and use the correct (modified) IP?
Frankly speaking this is the first time we see that a dynamic IP address is reported as a possible cause for connectivity issues. If network device (e.g. router) and local network in general is configured properly, there shouldn't be any issues with Internet access even if a network device is assigned another IP address.
Since we updated our hosts and viewers to the latest versions, we have noticed that the host service running on the end-user machines does not always inform the end-user that someone has connected. For example, previously the icon would turn red and the system would say "xxx has connected".
Unfortunately, this is a bug in version 184.108.40.206. You can update to the current 220.127.116.11 beta to have it fixed. Important: If you use self-hosted server, you should update the server to version 2.7 beta as well, as it is compatible with RU 6901 beta.
Since Host and Viewer are not bundled together and if backward compatibility breaks or changes on every version, then it should be more obvious to the user when there is a version mismatch that would prevent connection.
Newer Viewer can always connect to older Hosts. Compatibility the other way around is not guaranteed. That's why we highly recommend to at least make sure the Viewer version is the latest if it's not immediately possible to update the Hosts.
The Viewer knows the version of itself.
This is true.
The Viewer knows the version of the host.
Only when it connects or logs in on the Host at least once. If that happens, information about Host version becomes available in the address book. In the thumbnails view there is a tiny "msi" icon at the top right corner. In the Details view there are two dedicated columns:
The typical user (*cough* *cough*, myself included here. Though in this case, I KNOW I've read that before, just forgot) doesn't read documentation until they run into a problem. Errors and messages help tell the user where they should look in the documentation. The pop up informs the user what the exact problem is and what to do about it. Problem solved in minutes.
I can agree with this, but unfortunately, when version mismatch is involved there may be a problem or there may not. It's a probability thing depending on what specific feature the user is trying to use. Less intrusive methods of informing about version mismatch (such as the ones above) may work best especially on hundreds and thousands of address book records.