Feature request - storing AutomaticUpdater changes long term

I like how AutomaticUpdater shows the changelog as a menuItem when there is an update a user has to install. It would be nice if that menu item (with the version number and changes with that version) was always present in the menu underneath the green check mark (above or below 'Hide'), or we at least had the option of showing that info if we want to.

Does that make sense?

Hey William,

This isn't the first time we've had this request, but I still fail to see the end-user benefit. There's demonstrable benefit to showing users what will come in a new version (an incentive to upgrade). But I fail to see the benefit of showing them what was added.

The reason I ask is perhaps I'm failing to see a valid use case. Can you tell me why your users would need this?

In my case, it's a small convenience, because I also use the software I develop in my daily work.

So it's been handy for debugging when I happen to be at a workstation (while working) and I can quickly check for updates and see if the version and changelog matches current if there seems to be a problem. Not necessarily something I would have the end user see, but the option for me would be helpful.

In that case you can use the AutomaticUpdater as is with this bit of code.

When a new update successfully installs (i.e. when UpdateSuccessful event is called) store the latest changes to file:

#if DEBUG    SaveChanges(automaticUpdater.Changes);#endif

Then when you need to retrieve the changes for debugging purposes call a load function that loads and displays the changes.

Does this help?

Yes, perfectly. Thanks, Wyatt.

Quick question:

Do I use System.EventHandler or wyDay.Controls.SuccessHandler to check for the event?

The SuccessHandler. Here's how you can write it so it only compiles in your debug builds. In the constructor of your form add this:

#if DEBUG    automaticUpdater.UpdateSuccessful += automaticUpdater_UpdateSuccessful;#endif

Add the event handler and functions, like so:

#if DEBUG    void automaticUpdater_UpdateSuccessful(object sender, SuccessArgs e)    {        // an update has been successfully been installed        SaveChanges(automaticUpdater.Changes);    }


    void SaveChanges(string changes)    {        //TODO: save the changes to a text file    }


    string LoadChanges()    {        //TODO: load the changes    }#endif

Tell me if this helps.

Hmm...

I placed the eventhandler in the constructor like so

automaticUpdater1.UpdateSuccessful += automaticUpdater1_UpdateSuccessful;

and then the following on the form:

public void automaticUpdater1_UpdateSuccessful(object sender, wyDay.Controls.SuccessArgs e) { // an update has been successfully been installed SaveChanges(automaticUpdater1.Changes); }

public void SaveChanges(string changeLog) { changeLog = automaticUpdater1.Changes; AnestheticRecords.SetChangeLogInfo(changeLog); }

but the eventhandler doesn't seem to fire when I do an update.

Sorry, that's my fault. We've changed the behavior in the AutomaticUpdater 2.6.8 to fix a couple of bugs (including the one you spotted). In pre-AutomaticUpdater 2.6.8, after the "InitializeComponents()" function is called the UpdateSuccessful event has already been called.

Sorry about that. We're trying to get wyBuild 2.6.8 by the end of the week.

You can solve this in the meantime by adding the UpdateSuccessful event from the designer rather than adding the "automaticUpdater1.UpdateSuccessful += automaticUpdater1_UpdateSuccessful;" line to the constructor.

Thanks Sam, I'll just wait on that release since it's not a pressing issue.

Unless you have time for more explicit instructions for adding that code in the designer, as I can't seem to get that working either 🤔

wyBuild 2.6.8 is out. This problem is now fixed.

That's great.

Thanks, Sam.

Reply
Discard post