I posted this a couple of weeks earlier on the PM-Win list.

I recently upgraded from Windows 7 to Windows 10 Home. Pegasus works OK with no issues apart from when I close the program (either with the cross in the top corner or file/exit) the desktop doesn't always refresh and I am left with most of the Pegasus window showing even though the program itself has closed and disappears from the taskbar. I have to either click on one of the other programs on the taskbar, open another program, or select 'refresh' from the right menu from an exposed area of the desktop - ie anything else that causes the desktop screen to be refreshed. It doesn't usually occur if there is already a full screen program opened underneath Pegasus.

Although I have found on the web a similar effect with other programs (with no solution) and it seems not to be confined to Windows 10, on my computer Pegasus is the only program which shows this anomaly.

 A mild annoyance but which it would be nice to have a solution. Maybe I will have to wait for Pegasus 5 (2017, 2018, who knows).

Dave

[quote user="David Harris"]

I am working on a tool that will simplify the process of moving mailboxes around by doing all the necessary patching and file adjustment for you, but it won't be ready in time for v4.72. I wanted you to know that I'm aware of the issue though, and that there is a fix on the horizon.

[/quote]

Such a tool would be extremely useful indeed.

May I ask whether you plan to release it as a standalone utility or bundled in some future release of Pegasus mail?

Thanks in advance and all the best,

  Corrado

If you select multiple messages then hit F12 the properties window of the next selected message automatically opens when the existing one is closed but this is still a manual process.  I am not aware of a way to automate the removal of the "Is urgent" flag or to tell Pegasus Mail to disregard it when displaying in folder lists.

The most likely answer is that they fixed it.

The initial error suggested the problem was temporary/transitory (a 4xx code) and that the issue was with a remote server rather than Pmail.

Hope it remains fixed.

Thanks Michael, I was a little at sea,

Ron

Brian, you prompted me to do some experimenting, using new test messages in new test folders and with new simple annotations - so results are clear. I checked what was happening with files in the user Pmail/Mail directory each time. The results are:

- (Re your query) Moving a previously annotated message - now with the annotation absent - back to the new mail folder from a temporary folder does not re-establish links to the orphaned annotations.

-  Moving a still-annotated message back to the new mail folder from a temporary folder works fine and it appears there complete with the annotation.

- Green dots, indicating the existence of annotations, work exactly as one would expect they should i.e. once a message gets an annotation the green dot exists until the message is finally deleted, including in copies and following moves between folders.

-  Deleting a message with linked annotation from the new mail folder (i.e. a .CNM) or from another folder (i.e. a .PMM/.PMI) deletes any associated annotation, without leaving orphaned .PMN annotation files behind i.e. exactly as one would expect. (Note: To be clear, I did no direct editing of Pegasus files using Windows; always using Pegasus menus).

- Deleting a message that has an orphaned annotation 

(i.e. a .CNM or .PMM/.PMI exists as well as a previously associated .PMN in the user's Pmail/mail folder) - leaves the associated orphaned annotation behind.

- Re-indexing a test folder after moving a message out to the new mail folder - or to any other folder - caused the message to reappear in the test folder, complete with green dot but without the original annotation. It also exists in the folder to which it has been moved, but in that case the annotation is still attached (unless re-indexing has also occurred in that folder).

- Recovering deleted space, without subsequent re-indexing, has no impact on annotations. Recovering space and then re-indexing seems to prevent a moved message reappearing, so the question of associated annotation is irrelevant.

- Whenever an annotated message is moved (without re-indexing), its long Hex .PMN filename is changed.

- The impact on annotations of moving messages between folders is the same as copying messages between folders (as one might expect).

- Searching for references to the names of annotation files throughout the user's Pmail/Mail directory (i.e. checking in file contents), brings up no relevant results. However, as a link clearly does exist originally between the message file and its annotation, which was when I checked then I think Brian's conclusion that the link is encoded somehow in the relevant files.

Overall conclusion: The potentially very useful note-taking facility of annotations is fatally flawed by (a) the fact that re-indexing breaks the link between message and annotation and (b) the absence of any facility to remake these important links and indeed the lack of information on how to identify which orphaned annotation file belongs to which message file.

As an afterthought, the reappearance of previously deleted or moved messages upon re-indexing should ideally be addressed at some stage.

Likewise - it would appear that upgrading carries the bug over to 4.7.

anyone has a clue?   This is getting a problem, I can't file messages so the inbox gets overloaded :-(

There is a bug in the queue manager of v4.71 that results in the following behaviours:

1.  The queue manager window no longer automatically refreshes.  A refresh requires a close then open.

2.  The send now button does not actually send the messages.  I only converts them to final form.  A second click of the send button is required for final form messages to actually be sent.  IIRC, a refresh is required to see the final form messages.

There is a long discussion about this issue in this thread:

http://community.pmail.com/forums/thread/45231.aspx

Thanks..I will give it a look see

Thanks again

http://community.pmail.com/files/folders/pegadd/entry45339.aspx

Just noticed there are several identical pairs of folders. No idea how this happened, maybe when the hierarch file was rebuilt? There was one instance of 3 identical folders - when I clicked on one of them, Peg crashed and deleted all of them. So now I'm afraid to click on any of these. Wondering where to go from here, with the whole folder situation seeming to be such a mess.

Thanks Brian.  I knew there had to be a way to search a system file for my "hidden" file location, but I was never diligent enough to scan the documentation to find the right file.

Thanks to you, I now have it.

I'll also give your coding scheme a try. 

I've been using ISO-8859-1 forever and am now realizing that there are many special characters, especially foreign ones, that display only in UTF-8.

Before changing the default MIME character set in Pegasus are there any reasons not to use UTF-8 in 2016?

(Note that I still send only text emails)

Tnx :-)

Russell

Having just upgraded to V4.71, I noticed that the install exe, does not enable you to select a network location, either by mapped drive or Network Browsing.

I do not think that this is a Pegasus problem, but is more likely to be the problem with Network Browsing that has appeared since Microsoft's November Major update For Windows 10 (Version10586).

This problem has occurred before with Microsoft's lamentably untested updates, and is even more acute now with Windows 10, where you are not even told what it is updating, or have any choice whether you want the updates! If you have the Enterprise versions you have more control over how  the updates are delivered.

The solution that works for Pegasus Network Install is to use the explicit IP based locator for the resource when you are asked for the installation location. Do not use Browse as that is where the problem described above will prevent you from seeing your network device. Instead enter the URL in the form:

\\192.168.xxx.xxx\Network resource name\Pegasus Folder name\Programs

For example in our case this is:

\\192.168.1.21\SharedDocs\PegMail\Programs

This is why I always setup mapped shares to explicit  IP number based resources as problems have always existed with Microsoft's Master Browser service, (this is supposed to resolve the Network Names to devices). Mapping drives in this way avoids this problem.

I would be interested to know if others running network versions have the same problem, and, if so, under which versions of Windows.

For the record, we are running Windows 10 Pro x64 and we use ARM based NAS devices (QNAP).

[quote user="Brian Fluet"]Does replacement of the MAPIPM.DLL file require a subsequent execution of SETPMDEFAULT.PM?[/quote]

If MAPIPM.DLL is only replaced you don't need to re-run SETPMDEFAULT.PM, only if it's never been installed before.

Hi,

Thanks for your post. I experimented a bit more and got the following results under Debian with Wine:

1. Rather than renaming Renderer.pm, one can also edit it to replace the reference to IERenderer\IERenderer.dll with a reference to bearhtml.dll. However, this step isn't really needed at all (for me, at least), in fact.
2. Once you rename IERenderer.fff (the only thing which I really had to do), there's no need to rename IERenderer\IERenderer.dll any longer.

I'd like to add that I also had issues with running the setup program with simple 'wine w32-471.exe'. Wine complained about certain API calls being just stubs and finished without doing anything useful. Unfortunately, the installer isn't a ZIP archive any longer (unlike all previous versions up to 4.70!), so there was no option of simply upgrading my existing copy manually by overwriting the respective files from the archive. Anyway, I managed to fix it by starting 'wineconsole cmd' and running the setup from there - interestingly, that worked (FWIW, I started the wine console with root privileges, however the same was the case with 'wine w32-471.exe' mentioned above).

Tomas

Not as far as I am aware. Both STARTTLS and Direct SSL should work for SMTP, but you might be prompted by Gmail to move to OAUTH2.

Thanks for your reply, Michael! This information is good to know.

I'm now satisfied knowing that the problem doesn't involve IER, that Apple Mail TIFFs have been an issue, and that another Pegasus user (Ian) has exactly the same problem under the same unique circumstances.[Y]

Having this TIFF problem so rarely and using the browser interface as a quick workaround aren't big problems for me, so I wouldn't ask you to spend any valuable time trying to ascertain that it is indeed a TER problem.

I've bounced the failing message to myself, but then it doesn't reproduce the error exactly (after bouncing it, I CAN at least access the TIFF file in Pegasus attachment and save it to my computer - so there's yet another workaround!). Thus, I'm not sure I could ever have provided a truly "untouched failing" message for you (plus, I've since deleted the message in question and emptied the "trash").

To have delivered you a truly untouched failing message, I would have had to ask the original sender to send it to you directly from her computer - rather not do that.

But again, my thanks!

Now why didn't I figure that out?