View Full Version : HasMessages/GetMessages

03-05-2003, 04:15 AM
I have some problems getting my code to work as wanted when using the UpdateService at the start of my application. Main issue is that I don't want to run AutoUpdate() or AppUpdate() automatically before doing some prior checks on the messages available (I e.g. prompt the user is he really wants to run the update).

I now run HasMessages() first to check for messages, prompt the user if messages are available, and then run AutoUpdate() if the user chose to move on with the Upgrade. One problem with this approach is if I add a message that are set to be a scheduled event (i.e not "Next Use") in the admin page. In this case the HasMessages() function will return TRUE, while AutoUpdate() will return with bUpdateFound set to FALSE. This is very confusing for the user.

I therfore need a way to check for the type of messages available and have looked into the GetMessages() function instead. However I find the documentation on this function a bit wage, e.g. the documentation on the message types. I also find undocumented types (e.g. installSoftwareUpdate) in the .tlh header file.

1. Could someone give a good description of the the GetMessage function and the corresponding message types of the Message object ?

2. Is there some sample code on using GetMessages() in C++ available ? The on-line docs only have Visual Basic sample code.

Chris Woerner
03-05-2003, 12:23 PM
You can do what you want with GetMessages. However, there is an easier way.

Call AutoUpdate and set the nOptions parameter to 1. In doing that, AutoUpdate will return back if a critical update is available, but won't actually download it. If an update is available, then you can prompt the user.

Let me know if that does what you want...




If set to True, the download occurs silently and raises events to indicate its progress; these events trigger the following handler functions (see Remarks section):

OnProgressChanged([in] long nBytes, [in] long nPercent, [in] BSTR strTransferRate, [in] BSTR strTimeRemaining)
OnDownloadComplete([in] long nResultCode)

If bSilent is False, the Agent displays an Update Service-provided user interface to show progress messages.


If set to 0, the Agent downloads and launches the update, if there is one; if set to 1, the Agent checks for an automatic update but does not download it.

03-06-2003, 06:32 AM

Calling AutoUpdate with the nOptions parameter set to 1 solves my problem (I also managed to get the GetMessages() C++ code running though).

I now face the problem of implementing "Remind Me Later" functionality. As I understand from previous posts in this group, one problem when implementing this is that the LastCheckPerformed date in the .ini file isn't updated when I e.g. use HasIntervalElapsed(). I think I could modify the file myself, but that will probably only work if I'm logged on a as an administrator.

I read in a previous post that one solution to delay the check for updates is to first get the interval using GetScheduleInterval(), then add a value to the read interval and write this back again using SetScheduleInterval(). Wouldn't this mean that the update interval grows larger and larger as time goes on, which is certainly not what I want ?

Is there a way to force a "reset" of the LastCheckPerformed date without actually doing a check ?

Chris Woerner
03-11-2003, 12:30 PM
I understand your question/issue. The next release of the ISUS will contain a function to reset the lastcheckperformed date.

Having said that, your posting did prompt some research. Because when you call AutoUpdate and AutoUpdate finds a update, it should reset the lastcheckperformed date. It should reset the lastcheckperformed if you have nOptions parameter to 0 or 1. It should not matter. AutoUpdate found and update and either downloaded it or told the calling application. In either case, the lastcheckperformed should be updated.

In researching your question, we discovered a bug that is preventing AutoUpdate from reseting the lastcheckperformed if nOptions parameter is set to 1.

If you need a short-term work around, you can call GetMessages. That call always reset the date.