• This version applies some fixes to the browser menu handling to ensure a more consistent display of the manually added browser on Tools => Options => Hyperlinks. And it also takes care to reestablish the alphabetical sort order after switching IDs in Pegasus Mail.

• Then I've implemented a visual two step notification mechanism for IER updates like this:

  First one is an addition to the toolbar button with a proper description showing up below the mouse pointer (and sorry, the buffer size for the hint text is pretty limited):

  

  Second one is the menu with a red dot indicating the item to click for being directed to this history page here:

  

  Both of them will only show up if an update is actually available. The update check is done on startup if an Internet connection exists.

  Additionally I've transformed the former download link on this page into an easier to spot download "button" on top of the page.

• Starting with this version I'm going to provide a repository of previous IER versions linked to the respective version announcement so you might reinstall an older version if getting into serious trouble with an update. I'm certainly not going to do it for restoring little bugs like the one fixed with the previous version, though, i.e. 2.6.5.3 would replace 2.6.5.2 instead of both being provided.

The URLs are, as usual:

IER's history page: https://www.pmpgp.de/renderer/History.htm

Download link: https://www.pmpgp.de/renderer/IERenderer.zip

Thanks Michael. IER 2.6.5.4 has been solid so far.
I have a concern about the update notifications though. It is good for single user installations but not for multi-user ones. Most users of network installations can't do updates. A switch that disables update checking is a consideration but if isn't ideal because as entry in ierenderer.ini it would have to be set for every user. A consideration is to leave it off by default but I don't think that would be the best way to service the many. Maybe an option during installation to enable or disable it would be an answer. Then a network admin could flip it on for their user if they wanted update checking. I hope Joerg sees this and shares his thoughts.

Edit: The installer switch is not a panacea since IER typically gets updated by the unpack and copy method in networks installations, at least the ones I am familiar with.

I guess the easiest solution would simply be to block downloads from or access to pmpgp.de altogether. There's nothing else anyone would miss if doing so. Just let them get to see a 404 or what else would be appropriate in such an environment ...

Hi, I know there a new version which I not yet have checked.
Not sure if they are fixed but two things I noticed in version 2.6.5.4:

• IER update is available but I do not see any change on the Icon or menu, even after restart Pegasus.

• When I press manual the update button in the IER menu then I see the dialog to download the update. But regardless if I press 'Yes' or 'No' it will open in both cases the browser and download the update.

Same with us. The red exclamation mark does not apprear in 2.6.5.4, although 2.6.5.5 has been released.

I will update to 2.6.5.5 this evening when all users left the office.

OK, this may be something due to recent changes appplied to the confirmation dialog handling. But why the version detection doesn't appear to work (I assume the menu didn't show the red dot either?) is a mystery to me since the manual one uses the same routines as the new one - and I tested on Win 10 to be sure it doesn't only work on my Win 7 development system. I may have to provide you with a modified test version to figure out the reason since otherwise it's almost impossible to track this down.

Well, something I totally forgot about: IER has the capability of overriding options built-in ever since on two levels: First one would be to put an INI file into C:\ProgramData\Pegasus Mail\ (in Windows terms CSIDL_COMMON_APPDATA\Pegasus Mail\, i.e. for all users on a single machine), second on into C:\PMAIL\Programs\IERenderer\ where the latter would have highest priority. Doing so would override any user option defined in any of these files and can be done on the server (at least the latter) - that was my intention. I would only have to add the update option to this chain handler.

Since I don't administer a network installation anymore I will try to make comments without expressing preferences, leaving that to current admins.
Comment 1: A comment in the user configuration screen advising that configuration is being controlled by the email administrator could be of value.
Comment 2: If an .ini is added to \Programs\IERenderer then admins who manually update IER (unpacking the .exe) would need to be attentive to that .ini.

The idea is that the users just wouldn't get notified automatically at all, so the only thing left would by a dialog popping up for them when clicking the menu item or the respective link in the "About ..." dialog to explain why they can't update themselves. Or just remove or disable these links as well ... creating something new in the config dialog would be too much overhead, IMO, I would have to resize it or add another page.
Overriden config options already have a comment implemented, BTW, you may give it a try if being curious enough ...

And yes, admins would have to do their job, certainly ;-)

More comments, please!

Fixed.

OK, before doing the more elaborate stuff can you please reload 2.6.5.4 from the new "repository" and reinstall it, then try to get the update notification again. I did this as well on my Win 10 machine and it worked exactly the way it should, this is just to exclude that my release version happened to contain some debug code which it shouldn't have. I admit it's very unlikely since the repository version is just a (renamed) copy of the previous release, but you never know.

Here's the URL (if you don't pick it from the history page):
< https://www.pmpgp.de/renderer/repository/IERenderer-2654.zip >

I've now implemented the INI file switch which can be used by admins and also disables all update items elsewhere if set accordingly since this was a really quick and easy task. For now I haven't added any explanations or hints anywhere since I also had the idea that these items or links can even stay disabled for everyone as long as there's no update available, so why not just keep it like that?

I've now implemented the INI file switch which can be used by admins and also disables all update items elsewhere if set accordingly since this was a really quick and easy task. For now I haven't added any explanations or hints anywhere since I also had the idea that these items or links can even stay disabled for everyone as long as there's no update available, so why not just keep it like that?

And I found a second issue with manual update.
When I run over the menu in version 2.6.5.4 a manual update check and download the new version in browser, then I got a second task for winpm-32.exe.
This second IER task will not be closed with pegasus and run until I kill it with around 9% CPU.

I think there will no way to find the issue without any logs.

Good Morning,

I'm with you, Michael, disabling of any update notification would most probably prefered here with us in a multi-user network environment. But I understand PM-1 as well, that he would like to be informed about available updates.

My 20 users (12 Pmail / 8 TB) know that they are not able to install anything, neither locally nor on the server share. Further they would never check any software for available updates. They make their daily work until anything fails. Then they directly annoying me. I would also assume that they even wouldn't notice the red update mark at the IER icon .
I'm regularly going through the forum to check whether a new IER update is available, extract it from the setup.exe and copy the newer files of the setup assembly to the server share using admin rights. This works for me.

Nevertheless I will still test any new functions including notification in case you need a network installation reply. But this can last always 2 or 3 days until I find time and simultaneously all users are out of office and also not logged-in via VPN/RDP from home office, since IER DLL and Libtidy are locked during running Pmail session.

I try to re-install the updated 2.6.5.4 this evening.

PS: Not noticing the icon is certainly pretty common ...

I haven't seen any update indicators either while running 2.6.5.4, even after a reinstall done yesterday (no exclamation point, no red dot). My test of the manual update function downloaded the file as expected. No additional tasks were triggered.

I've already removed the code to blame (I actually think it was) yesterday since it caused weird results with regard to the update checking here as well when trying to directly open the history page from the menu (instead of doing it via another confirmation dialog as done manually), yet I don't still understand what actually caused this issue (only) under certain conditions. The purpose of this thread was to just launch the browser (in all cases when it's invoked, i.e. for links, displaying messages or starting downloads) and then leave it alone so Pegasus Mail can proceed with its own work without having to wait until ShellExecute() returns. So maybe I already found the solution, time for another update for you to try, I guess - but unfortunately this requires two updates in a row since otherwise it won't trigger an update using the new version ... :-/