Attachments don't work in read windows

screenshot showing the problem - Moved from SF. Original author: saimobvq

Unfortunately this is a normal and known behaviour. The problem is, that the icon type is identified with DefIcons and for DefIcons to work properly it requires access to the complete file content.

Now, as you can see from your example screenshot, the left window correctly identified the "test.lha" as an "LhA archive". However, the size of it has the "~" sign which says that this is an estimate of the real size. Then after you double-clicking on it, YAM extracts the file from the raw email (e.g. via a base64 decoding) and is then able to identify the real size (535 bytes) and is also able to load the real icon via DefIcons.

So I am sorry, but this is a known and totally normal behaviour as the files of attachments are only extracted/decoded from the raw mails when they are actually used as otherwise we would have to decode ALL attachments right away when you open an email. This would, however, require additional processing power and thus slow down the reading of emails.

Moved from SF. Original poster: damato

Thanks for the quick reply.

OK, I understand (and agree to) the choice of limiting decoding only when requested by the user. However, is it also the intended behaviour that double-clicking on the attachment only causes the full type detection? I mean, in the past, double-clicking would trigger the action associated to the file type (f.ex., on my system, clicking on attached LHA archives would open the attachment with UnArc; similarly, a picture would be opened with a viewer, a text file with a reader, and so on)? While the first problem I mentioned is a cosmetic one of very little importance, the second regards an important functionality.

Moved from SF. Original poster: saimobvq@…

Of course, If double clicking on the attachment icon does not open multiview or your user configured action from the preferences this points out a bug in YAM. If this is the case please state so here and we will investigate further. However, double-clicking should open multiview & friends.

Moved from SF. Original poster: damato

Yes, that's precisely what I meant at point 2 of my original report.

Moved from SF. Original poster: saimobvq@…

Is this issue still valid? If yes, then please check if you have any MIME type like application/x-lha or similar configured. Also run Snoopy/SnoopDOS in the background to check what is really happening on your system. Maybe a program is started correctly but fails silently.

Does this issue also occur with other file types, i.e. pictures?

Moved from SF. Original poster: thboeckel

mmm... MIME preferences... I don't have any type set, but I do have a
default viewer... and that's it! The viewer was moved from the location
indicated in the preferences, so it was entirely my fault!
I'm very sorry for bothering you for such a stupid mistake. My humblest
apologies.

Moved from SF. Original poster: saimobvq@…

Ok, marking this bug as "later".

We should think about some kind of error message when executing commands.
But since the very same function is also used during the mail filtering
process an error message would block the whole process.

The best solution would be to finally fire up our thread implementation
and let the thread to the dirty error handling work.

Moved from SF. Original poster: thboeckel

As we want to address that issue in 2.7 I am going to mark the milestone here and make it dependent on the multithreading information.

(In [4918]) * misc: a failed command execution will now always be reported using the well

known error message window. This finally closes #11. The main thread is no
longer an embedded structure in the global data but allocated dynamically
like any other subthread. First, this is more consistent, and second, this
causes much less dependencies of the source code files.