If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rating: | Display Modes |
#46
|
|||
|
|||
e-mail graphics mystery
Mayayana wrote:
| it, copy its raw source and post it here for others to analyze. I | suspect either externally linked images or scripting is at fault. He's already posted links to an email that works and one that doesn't, as .eml files. They're very similar, but the newer one is slightly different, with different doctype. See a few posts back for the links. Both emails have the images embedded; no remote links. I found that both emails work fine for me in both OE6 and TBird 24. So the issue seems to *probably* be an overlooked WM setting. One link Recta gave was: https://dl.dropboxusercontent.com/u/...ber%202014.eml Do you see headers in there, like the Content-ID headers to match up with all the cid (content identifier) references? I see the HTML code that would be contained within the HTML MIME section in the raw source of the e-mail (but not even the MIME headers in the body that delineate the HTML MIME section). I don't see the MIME section for the plain text part (if the sender included both text and HTML versions of the message to ensure non-HTML clients could still read the message). I don't see any of the headers, especially the Content-ID and other content headers. I don't see the MIME parts containing the encoded strings that define the images (if they were inline or attached instead of hyperlinks pointing to external content). |
Ads |
#47
|
|||
|
|||
e-mail graphics mystery
| Do you see headers in there, like the Content-ID headers to match up
| with all the cid (content identifier) references? | It looks OK to me. I may have overlooked some syntax error, but I see the headers, the content and the base-64 encoded images. Any quirks can't be too serious, since I can see the images in two different email programs. I should note that I "cheated". The HTML portion was such a mess I ran it through the following VBS code to render it reasonably readable: s1 = Replace(s, "=0A", vbCrLf, 1, -1, 1) s1 = Replace(s1, "=09", Chr(9), 1, -1, 1) s1 = Replace(s1, "=3D", Chr(1), 1, -1, 1) s1 = Replace(s1, "=", "", 1, -1, 1) s1 = Replace(s1, Chr(1), "=", 1, -1, 1) | I see the HTML code that would be contained within the HTML MIME section | in the raw source of the e-mail (but not even the MIME headers in the | body that delineate the HTML MIME section). I don't see the MIME | section for the plain text part (if the sender included both text and | HTML versions of the message to ensure non-HTML clients could still read | the message). I don't see any of the headers, especially the Content-ID | and other content headers. I don't see the MIME parts containing the | encoded strings that define the images (if they were inline or attached | instead of hyperlinks pointing to external content). |
#48
|
|||
|
|||
e-mail graphics mystery
| I think you're chasing a red herring here. Old
| | I'm not a fisherman. | | The same e-mail does show up in WM on Windows 7, and does not show up in | (the same) WM on Vista. Then I would suggest carefully looking through all of the possible WM settings on each system again to see if you missed some display option. The business of searching through Registry PNG settings is beyond digression. It has nothing to do with displaying images in your email. As I already noted, it displays in OE6 and TBird 24, and you said it displays in IE. So why would you guess that the problem is PNG associations or faulty code? (Paul is very knowledgeable and very helpful with his time, but if you ask him how to get to Pittsburgh you'll probably end up learning all about the composition of the inks on your roadmap. He'll often provide good directions, too, but you don't want to mistake ink chemistry explanations for directions. |
#49
|
|||
|
|||
e-mail graphics mystery
In message , Char Jackson
writes: On Thu, 1 Jan 2015 18:42:37 +0000, "J. P. Gilliver (John)" wrote: IE didn't always come with Windows: I can't remember whether it was Windows 95 or 98 (or 98SE) that first included it. Windows 3.1 certainly didn't - and in those dim past days, IE _was_ available as a standalone download, just as Mozilla - later Netscape - was (initially not free, though I think IE always was; it certainly was free before Netscape was, which in large part did for the latter, except among enthusiasts and Microsoft-haters (who were still using Windows). In a discussion of pre-Netscape days, I expected to see mention of Mosaic, rather than Mozilla. Sorry, yes, you're right. It felt wrong as I was typing it, but I couldn't think why. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf - royalty, the Prime Minister, God, even Simon Cowell. - Carol Vorderman, in Radio Times, 27 October - 2 November 2012 |
#50
|
|||
|
|||
e-mail graphics mystery
In message , Stan Brown
writes: On Thu, 1 Jan 2015 18:32:58 +0000, J. P. Gilliver (John) wrote: (As an aside, what possible purpose does 'alt=""' serve? I have an interest in accessibility matters, and my blind friends find places that supply a text alternative for images [that's what "alt" is about] quite useful; however, if it's going to be a null string, I see no point in including it at all. The only possible reason I can think of for it being there is a brain-dead automatic code generator that thinks all images _have_ to have an alt= tag [and probably many other similar wastes of bandwidth].) Modern specs of HTML require the alt attribute with every img tag. In Then the specs are an ass; requiring the presence of something whose sole purpose is to satisfy the spec.s, and whose absence will not break any browser I've come across, is ... general, people (or code generators) that insert an empty string are complying with the letter of the spec but doing violence to its I like your "doing violence to" (-:. spirit. The exception is when the images are mere eye candy and don't contribute any actual information. That's far more often the case than otherwise, these days )-: (-: -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf - royalty, the Prime Minister, God, even Simon Cowell. - Carol Vorderman, in Radio Times, 27 October - 2 November 2012 |
#51
|
|||
|
|||
e-mail graphics mystery
Mayayana wrote:
Do you see headers in there, like the Content-ID headers to match up with all the cid (content identifier) references? It looks OK to me. I may have overlooked some syntax error, but I see the headers, the content and the base-64 encoded images. Any quirks can't be too serious, since I can see the images in two different email programs. Then it must be how I'm retrieving the .eml file. I'll hunt around for another method (i.e., not using IE which wants to display the text file instead of download it). The Dropbox "test" folder isn't shared so I can't step back (up) to list the files within it to elect to force a download. |
#52
|
|||
|
|||
e-mail graphics mystery
| Modern specs of HTML require the alt attribute with every img tag. In
| | Then the specs are an ass; requiring the presence of something whose | sole purpose is to satisfy the spec.s, and whose absence will not break | any browser I've come across, is ... | It shouldn't break any browser. HTML was designed originally with the idea that browsers would just ignore anything irregular. (As opposed to CSS, which seems to get ignored after any fault in the code.) I think the idea of making ALT standard was probably related to accessibility, so that people who don't see images can know what's supposed to be in that spot. In any case, there's no need to be concerned with it. It might not pass a W3C test, but that really has nothing to do with anything when it comes to real world webpages. |
#53
|
|||
|
|||
e-mail graphics mystery
"VanguardLH" schreef in bericht ... Mayayana wrote: Do you see headers in there, like the Content-ID headers to match up with all the cid (content identifier) references? It looks OK to me. I may have overlooked some syntax error, but I see the headers, the content and the base-64 encoded images. Any quirks can't be too serious, since I can see the images in two different email programs. Then it must be how I'm retrieving the .eml file. I'll hunt around for another method (i.e., not using IE which wants to display the text file instead of download it). The Dropbox "test" folder isn't shared so I can't step back (up) to list the files within it to elect to force a download. Yes I used a public dropbox folder. The folder itself can't be shared, only the two example files within it. Besides, I have no other files in my dropbox as regards to this subject. -- |\ /| | \/ |@rk \../ \/os |
#54
|
|||
|
|||
e-mail graphics mystery
Linea Recta wrote:
"VanguardLH" schreef in bericht ... Mayayana wrote: Do you see headers in there, like the Content-ID headers to match up with all the cid (content identifier) references? It looks OK to me. I may have overlooked some syntax error, but I see the headers, the content and the base-64 encoded images. Any quirks can't be too serious, since I can see the images in two different email programs. Then it must be how I'm retrieving the .eml file. I'll hunt around for another method (i.e., not using IE which wants to display the text file instead of download it). The Dropbox "test" folder isn't shared so I can't step back (up) to list the files within it to elect to force a download. Yes I used a public dropbox folder. The folder itself can't be shared, only the two example files within it. Besides, I have no other files in my dropbox as regards to this subject. FYI: In the webmail UI to your Dropbox account, hover the mouse over the folder. To their right will appear a "Shared" button. Click on it to share the folder. Giving a link to a file provides shared access only to the file. The other person cannot merely walk up the URL to get at the folder. A separate link is needed that points to the folder (to then see a list of files under that folder). (Been too busy for me to figure out another method of downloading the ..eml file rather than IE display it which IE likes to do for any file that is all plain text content. Problem is that IE will display the HTML portion so I can't see the headers that Mayanana can see. Have to find another way to yank the file from your test folder.) |
#55
|
|||
|
|||
e-mail graphics mystery
Ah, got it out of the web browser's TIF (temporary internet files)
although with UAC and protected mode in IE the path wasn't so straight forward. Can see all of the .eml content now. I see there in no Content-Type for a plain text version of the newsletter. They probably want to ensure you see all those cutsy images. The also probably want to ensure you see it formatted correctly. That lack of a text version of the message is typical with bulk mail. I now see all the MIME parts for the embedded or inline images (Content-Disposition: inline). There are 24 cid references but only 13 MIME parts to reference of which 1 is for the HTML formatted message. So there are 24 CIDs inside the HTML message but only 12 MIME parts for those CIDs to reference. Likely there is duplication. So here are the CIDs in the HTML message, in order of appearance, and the image (filename) in the corresponding MIME part: 72657d204c517b477133da0bb7738696@RESOURCE ---.--- background-kerst.jpg 72657d204c517b477133da0bb7738696@RESOURCE ---| 72657d204c517b477133da0bb7738696@RESOURCE ---| 72657d204c517b477133da0bb7738696@RESOURCE ---' f123c3c8de676728340785356023b87e@RESOURCE ------- logo.png 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---.--- arrow.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 5573342b8a1c546a9a5d8d96284007da@RESOURCE -- | -- bellen_algemeen-newstyle.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 32ce697041c6ff4bfe5f140c779a7328@RESOURCE -- | -- fritzdect200.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 59ebea15b00cc0e0ace9f8fee8960de2@RESOURCE -- | -- glazenhuis.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 57a521298dd0947d75c22f1699b3f5ec@RESOURCE -- | -- column.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---' 40e6b8a444b9f3451391cc573c96c56e@RESOURCE ------- icon-facebook.png 4e7f1a0a0a76ace0b9f5e6d61c0f6165@RESOURCE ------- icon-twitter.png 9a0ea7b769afd462aa925fe251ed2177@RESOURCE ------- icon-blog.png dd12ceaa05a3f1a90d1356648c15fe48@RESOURCE ------- divider-kerst.gif 8945717fc3d3f0e8cdd792bcf058b222@RESOURCE ------- mini-divider.gif So 24 CIDs (12 duplications) point at 12 MIME parts. The Content-Type header specifies MTQxODAzNTg2NTU0ODU4Mjk5NzE1ODA as the ID string and each MIME part uses that ID so they all match. So it all looks good. It's possible the MIME parts got corrupted (so they won't display due to an error in trying to show an invalid file format). So I went to http://www.motobit.com/util/base64-decoder-encoder.asp and inserted the base64 string in each MIME part (other than the text/html one for the message) to make sure the images would open okay and looked okay. I save them at tinypic.com (some you might have to zoom in to see them, and make sure not to confuse Tinypics other images with the one that I uploaded): background-kerst.jpg -- http://tinypic.com/r/rlhybr/8 logo.png -- http://tinypic.com/r/2zegq3d/8 arrow.jpg -- http://tinypic.com/r/33aweax/8 bellen_algemeen-newstyle.jpg -- http://tinypic.com/r/2cxylw9/8 fritzdect200.jpg -- http://tinypic.com/r/2zywye9/8 glazenhuis.jpg -- http://tinypic.com/r/2vnkjtd/8 column.jpg -- http://tinypic.com/r/15dnno7/8 icon-facebook.png -- http://tinypic.com/r/2ilef10/8 icon-twitter.png -- http://tinypic.com/r/53l1dg/8 icon-blog.png -- http://tinypic.com/r/j6q5wj/8 divider-kerst.gif -- http://tinypic.com/r/2cnv390/8 mini-divider.gif -- http://tinypic.com/r/20iicn9/8 (I'll have to go elsewhere to upload pics since Tinypics has made their pages so damn "busy" that the noise confuses the visitor as to what they should be looking at.) They all look like good images so the MIME parts containing the encoded strings for the images were okay. The CID references are correct. When I load the .eml into a web browser, the headers and stuff before the HTML tag are ignored as well as after the /HTML tag (although the CID references are still obeyed). All the images display okay (the mini-divider.gif is very hard to see but is between the "Algemene voorwaarden" and "Privacyverklaring" text objects at the very bottom of the page). So the HTML renders okay and the images show okay which means their references are valid and the MIME parts defining those images are not corrupted. For: https://dl.dropboxusercontent.com/u/...ber%202014.eml Was this is the e-mail where you could not see some of its [image] content or did I pick the wrong one? Seems it is all correct. There's nothing missing or corrupted in the HTML-formatted e-mail. While web browsers are forgiving of syntax errors (and why IE failed the ACID tests for so long because it measured how sloppy was a web browser in permitting common faults), the HTML rendering in an e-mail client may not be so forgiving. I ran the HTML MIME part's code through a validator (http://validator.w3.org/check) and it found lots of errors, like forgetting to close an HTML tag. I suspect all of the "missing end tag" errors are due to the e-mail using instead of / as the closing HTML tag. That was because the DOCTYPE tag said to use transitional style HTML which presumes / to close a tag, not just . Then there are attributes or their values that are not valid. The web browser will ignore them but perhaps not the more simpler or basic HTML renderer in an e-mail client. So while the HTML gets rendered okay in a web browser, the same may not be true of whatever HTML renderer is used within the e-mail client. Also, just because an e-mail client may use the IE libraries to render HTML-formatted e-mails does not mean the e-mail client's use of those IE libs permits web browser-like rendering. So if this was the e-mail where you had missing images or problems rendering it, the problem seems two-fold: the newsletter sender needs to address their syntax errors but the rendering problem may still be within your e-mail client of choice. |
#56
|
|||
|
|||
e-mail graphics mystery
"VanguardLH" schreef in bericht
... Ah, got it out of the web browser's TIF (temporary internet files) although with UAC and protected mode in IE the path wasn't so straight forward. Can see all of the .eml content now. I see there in no Content-Type for a plain text version of the newsletter. They probably want to ensure you see all those cutsy images. The also probably want to ensure you see it formatted correctly. That lack of a text version of the message is typical with bulk mail. I now see all the MIME parts for the embedded or inline images (Content-Disposition: inline). There are 24 cid references but only 13 MIME parts to reference of which 1 is for the HTML formatted message. So there are 24 CIDs inside the HTML message but only 12 MIME parts for those CIDs to reference. Likely there is duplication. So here are the CIDs in the HTML message, in order of appearance, and the image (filename) in the corresponding MIME part: 72657d204c517b477133da0bb7738696@RESOURCE ---.--- background-kerst.jpg 72657d204c517b477133da0bb7738696@RESOURCE ---| 72657d204c517b477133da0bb7738696@RESOURCE ---| 72657d204c517b477133da0bb7738696@RESOURCE ---' f123c3c8de676728340785356023b87e@RESOURCE ------- logo.png 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---.--- arrow.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 5573342b8a1c546a9a5d8d96284007da@RESOURCE -- | -- bellen_algemeen-newstyle.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 32ce697041c6ff4bfe5f140c779a7328@RESOURCE -- | -- fritzdect200.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 59ebea15b00cc0e0ace9f8fee8960de2@RESOURCE -- | -- glazenhuis.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 57a521298dd0947d75c22f1699b3f5ec@RESOURCE -- | -- column.jpg 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---| 18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---' 40e6b8a444b9f3451391cc573c96c56e@RESOURCE ------- icon-facebook.png 4e7f1a0a0a76ace0b9f5e6d61c0f6165@RESOURCE ------- icon-twitter.png 9a0ea7b769afd462aa925fe251ed2177@RESOURCE ------- icon-blog.png dd12ceaa05a3f1a90d1356648c15fe48@RESOURCE ------- divider-kerst.gif 8945717fc3d3f0e8cdd792bcf058b222@RESOURCE ------- mini-divider.gif So 24 CIDs (12 duplications) point at 12 MIME parts. The Content-Type header specifies MTQxODAzNTg2NTU0ODU4Mjk5NzE1ODA as the ID string and each MIME part uses that ID so they all match. So it all looks good. It's possible the MIME parts got corrupted (so they won't display due to an error in trying to show an invalid file format). So I went to http://www.motobit.com/util/base64-decoder-encoder.asp and inserted the base64 string in each MIME part (other than the text/html one for the message) to make sure the images would open okay and looked okay. I save them at tinypic.com (some you might have to zoom in to see them, and make sure not to confuse Tinypics other images with the one that I uploaded): background-kerst.jpg -- http://tinypic.com/r/rlhybr/8 logo.png -- http://tinypic.com/r/2zegq3d/8 arrow.jpg -- http://tinypic.com/r/33aweax/8 bellen_algemeen-newstyle.jpg -- http://tinypic.com/r/2cxylw9/8 fritzdect200.jpg -- http://tinypic.com/r/2zywye9/8 glazenhuis.jpg -- http://tinypic.com/r/2vnkjtd/8 column.jpg -- http://tinypic.com/r/15dnno7/8 icon-facebook.png -- http://tinypic.com/r/2ilef10/8 icon-twitter.png -- http://tinypic.com/r/53l1dg/8 icon-blog.png -- http://tinypic.com/r/j6q5wj/8 divider-kerst.gif -- http://tinypic.com/r/2cnv390/8 mini-divider.gif -- http://tinypic.com/r/20iicn9/8 (I'll have to go elsewhere to upload pics since Tinypics has made their pages so damn "busy" that the noise confuses the visitor as to what they should be looking at.) They all look like good images so the MIME parts containing the encoded strings for the images were okay. The CID references are correct. When I load the .eml into a web browser, the headers and stuff before the HTML tag are ignored as well as after the /HTML tag (although the CID references are still obeyed). All the images display okay (the mini-divider.gif is very hard to see but is between the "Algemene voorwaarden" and "Privacyverklaring" text objects at the very bottom of the page). So the HTML renders okay and the images show okay which means their references are valid and the MIME parts defining those images are not corrupted. For: https://dl.dropboxusercontent.com/u/...ber%202014.eml Was this is the e-mail where you could not see some of its [image] content or did I pick the wrong one? Seems it is all correct. There's nothing missing or corrupted in the HTML-formatted e-mail. Yes this is the newer edition of which html does not show up (on the Vista PC). This goes for all newer editions of this newsletter from a certain date. The older ones gave no problems on both computers. I don't remember having problems with other html mail yet... While web browsers are forgiving of syntax errors (and why IE failed the ACID tests for so long because it measured how sloppy was a web browser in permitting common faults), the HTML rendering in an e-mail client may not be so forgiving. I ran the HTML MIME part's code through a validator (http://validator.w3.org/check) and it found lots of errors, like forgetting to close an HTML tag. I suspect all of the "missing end tag" errors are due to the e-mail using instead of / as the closing HTML tag. That was because the DOCTYPE tag said to use transitional style HTML which presumes / to close a tag, not just . Then there are attributes or their values that are not valid. The web browser will ignore them but perhaps not the more simpler or basic HTML renderer in an e-mail client. So while the HTML gets rendered okay in a web browser, the same may not be true of whatever HTML renderer is used within the e-mail client. Also, just because an e-mail client may use the IE libraries to render HTML-formatted e-mails does not mean the e-mail client's use of those IE libs permits web browser-like rendering. So if this was the e-mail where you had missing images or problems rendering it, the problem seems two-fold: the newsletter sender needs to address their syntax errors but the rendering problem may still be within your e-mail client of choice. And don't forget: we're talking about the _same_ e-mail client on both computers! Only different OS. AND: I also tested with virus scanner and firewall disabled. And security settings in WM to display all html. That's why I have "mystery" in my subject :-( Thanks for all the effort so far. -- |\ /| | \/ |@rk \../ \/os |
#57
|
|||
|
|||
e-mail graphics mystery
Now I remember that when I transferred WM to my PC after installing Windows
7 (where it works fine), I applied some or all registry files. I got the howto information from a web site, but this site seems down nowadays. The registry files are "for making WM work on Windows 7", so I didn't dare to apply them on Vista. Also, this shouldn't be necessary since WM was already on Vista when I bought the notebook... I don't know if you're a registry guru, but I'll paste a link to the registry files... you never know if it gives a lead. https://dl.dropboxusercontent.com/u/...0in%20w7.r ar -- |\ /| | \/ |@rk \../ \/os |
#58
|
|||
|
|||
e-mail graphics mystery
Linea Recta wrote:
Now I remember that when I transferred WM to my PC after installing Windows 7 (where it works fine), I applied some or all registry files. I got the howto information from a web site, but this site seems down nowadays. The registry files are "for making WM work on Windows 7", so I didn't dare to apply them on Vista. Also, this shouldn't be necessary since WM was already on Vista when I bought the notebook... I don't know if you're a registry guru, but I'll paste a link to the registry files... you never know if it gives a lead. https://dl.dropboxusercontent.com/u/...0in%20w7.r ar Without going into looking into the .reg files, their names suggests that they carry the settings for WM. For example, a couple associate the mailto:// protocol with WM as the handler, others define WM as the default mail client and the default news[groups] handler. I didn't see any that specifically delineated what image handlers would get used. So you used them to setup WM on Windows 7. Did you get those .reg files from your Vista host or were they someone else's settings? If someone else's, how did you "migrate" your WM settings from Vista to 7? While drastic, I'm wondering if you can close WM, go into Add/Remove Windows Components, remove (deselect) Windows Mail, reboot, and re-add Windows Mail. Export what you can from Windows Mail to save elsewhere. If you use IMAP accounts, you don't need to store their e-mails because when you re-add WM or install another e-mail client then all the e-mail you saw before are still up on the server to sync with the new e-mail client. If you use POP (and did not enable the "leave on server" option) then the local copy in WM's message store is the only copy, so you have to save those e-mails if you don't want to lose them. First see if making WM rebuild its message store resolves the problem: - Exit WM. Use Task Manager to make sure its process unloads. - Find where is your WM message store under your own profile folder (it's probably #6 in the http://tinyurl.com/aqz8759 article). Copy the folder (with everything under it) to somewhere else. Delete everything under the folder but not the folder itself. - Reboot Windows. - Start WM. It will rebuild a default message store under your profile. - Depending on whether you have POP or IMAP accounts: o If you use POP to access your e-mail accounts: * Go to the File - Import - Messages menu. Select Windows Mail 7. * Browse to where you saved a copy of your message store. o If you use IMAP, just reconnect to your IMAP accounts. What you saw in your client for the IMAP accounts is still what is on the server. If that doesn't help, see if reinstalling WM fixes its problem handling some image content: - Exit WM. - Copy your profile's WM message store folder to elsewhere. Delete the folder. - Copy and then delete the %progdir%\Windows Mail folder. - Uninstall WM (Add/Remove Windows Components). - Reboot. Perhaps not necessary but too often required in Windows. - Re-add WM (Add/Remove Windows Components). - Do the import of your copied message store (for POP accounts). Hopefully that resets WM to its install-time state and any remnant registry entries after the uninstall are either overwritten with the reinstall or don't relate to your problem. Before doing the uninstall and reinstall of WM trying to fix it, I'd save a full image backup (plan an escape route to get back to what you had before). |
#59
|
|||
|
|||
e-mail graphics mystery
VanguardLH wrote:
Linea Recta wrote: Now I remember that when I transferred WM to my PC after installing Windows 7 (where it works fine), I applied some or all registry files. I got the howto information from a web site, but this site seems down nowadays. The registry files are "for making WM work on Windows 7", so I didn't dare to apply them on Vista. Also, this shouldn't be necessary since WM was already on Vista when I bought the notebook... I don't know if you're a registry guru, but I'll paste a link to the registry files... you never know if it gives a lead. https://dl.dropboxusercontent.com/u/...0in%20w7.r ar Without going into looking into the .reg files, their names suggests that they carry the settings for WM. For example, a couple associate the mailto:// protocol with WM as the handler, others define WM as the default mail client and the default news[groups] handler. I didn't see any that specifically delineated what image handlers would get used. So you used them to setup WM on Windows 7. Did you get those .reg files from your Vista host or were they someone else's settings? If someone else's, how did you "migrate" your WM settings from Vista to 7? The other part of this, is Internet Explorer settings, and how those are inherited by other things. IE settings influence how other browsers handle HTML (Firefox honors those settings), as well as affecting how the HTML engine works. And WM, being Outlook Express in disguise and dependent on an HTML engine, would be a prime candidate for IE settings influences. So a reg file with "mailto" settings, isn't likely to be reloading the 2000 registry settings used by the zones in IE. I wonder how difficult it would be, to "reset" the IE security settings, and give the test cases another try ? Paul |
#60
|
|||
|
|||
e-mail graphics mystery
Paul wrote:
The other part of this, is Internet Explorer settings, and how those are inherited by other things. IE settings influence how other browsers handle HTML (Firefox honors those settings), as well as affecting how the HTML engine works. And WM, being Outlook Express in disguise and dependent on an HTML engine, would be a prime candidate for IE settings influences. So a reg file with "mailto" settings, isn't likely to be reloading the 2000 registry settings used by the zones in IE. I wonder how difficult it would be, to "reset" the IE security settings, and give the test cases another try ? Under Internet Options, Advanced tab, is a Reset button. That resets IE back to install-time defaults. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|