I'm attempting to check for updates when my application launches using pAgent.AutoUpdate. I received an 'error' that said "Component Request Pending" and the application appears to lock up. I then went to the InstallShield website and noticed that it appeared to be down.
Two questions:
First - was the 'error' I received the result of the site being inaccessible?
Second - is there a way to trap for this error so the application won't lock and continues on normally?
I can't recreate the error because the site is up and the component request is not locking.
I think I answered this in another thread, but for sake of completeness, I will post here as well.....
Let me quickly describe the behavior of the two functions related to connectivity checking.... There is more information on AppUpdate in the help and in KB article Q106331.
AppUpdate() - AppStart: Checks for an internet connection. First, it asks Windows if a connection is present. Unfortunately Windows sometimes tells you a connection is there when it isn't. So as a second check, it pings the Update Service server. If there is no connection (or no server), the AppUpdate will end silently.
AutoUpdate(): This doesn't perform a check for an internet connection. If you are using this call, we HIGHLY recommend that you first call IsConnected() to determine if a connection is present. That will avoid your application locking on you. I think you found this the hard way. Sorry about that. I will look to improve our documentation on this.
So the IsConnected call will both check for an internet connection AND check to see that the Installshield servers are up?
Because if it only checks for an internet connection, then it won't eliminate the scenario where the Update Services server is down.
----------------------------------------
Also, I seemed to have controlled the problem (or at least it has yet to appear again) by using AppUpdate at StartUp instead of AutoUpdate - I do a IsConnected followed by a HasMessages and then the AppUpdate (this mimics the silent close if no updates are available). Again, not sure it's the perfect solution, but it seems to work.
IsConnected does check for an Internet connection and to see if it can reach the Update Service website.
In terms of your solution....."I do a IsConnected followed by a HasMessages and then the AppUpdate (this mimics the silent close if no updates are available"
You are actually duplicating work that AppUpdate does for you. Internally, AppUpdate (AppStart) does the following:
> calls IsConnected > if connected, check for critical messages (uses HasMessages) > if no critical messages, check scheduled interval > if expired, check for scheduled messages
This is documented in the Update Service help in a flow chart. To see the flow chart, do a search on AppUpdate(). Down where it lists the event, select the AppStart event. It will expand into the flow chart.
Bottom line.....When you use AppUpdate(), you don't need those other calls. If there are no updates (or no connection) during start-up, the Update Service will not show a UI.
I was aware I was duplicating those procedures, but since I was using AppUpdate where AutoUpdate should have been used, I only wanted AppUpdate to run if there were messages. By duplicating those procedures prior to the AppUpdate I was able to get AppUpdate to mimic an AutoUpdate and not run if there weren't messages.
Since I now know the IsConnected not only checks for internet connections but also whether or not Update services is available, I will switch back to AutoUpdate (after an IsConnected call).
