Why does my D2009 exe produce emails with attachments named ATTnnnnn.DAT when the same source code compiled in D2007 produces emails with attachments correctly named with the original file name?
I am using the respective Indy libraries that come with D2007 and D2009. Not having the original file name on the attachment prevents users from being able to double click the attachment to open it (typically attachments are Excel spreadsheets).
Note: code is identical - just the compiler and Indy libraries vary. The attachment sent by the D2009 exe can be saved and renamed to say zzzz.xls and then opens correctly -- ie the email and attachment go through correctly -- it is just the email attachment file name that is messed up.
Someone suggested the attachment headers are corrupted. Has Indy been broken? The code to reproduce is stock standard code that can be found on many websites, but I can post if necessary. Thx in advance.
I have found the problem - please see the adug.com.au mailing list for exact
details of the solution, but in summary -- the version of Indy that comes
with D2009 (version 10.2.5) has 2 errors in the IdMessageClient.pas unit in
two lines that set the name= and filename= in the attachment part processing
(one line number is 1222 from memory and the other is a few lines earlier;
sorry I am at home now; I fixed things this evening at work). The lack of these semi-colons causes the attachment header to be badly formed and Outlook generates a name of its own for the attachment.
The fix is to output a semi-colon ( ; ) before outputting the name= or
filename= tokens. Then Indy needs to be rebuilt.
I compared the D2007
version of Indy (10.1.5) and can see it always puts the semi-colon at the
end of the Content-Type line thus avoiding the problem that has crept into
the version included with D2009.
I recommend updating to the current Tiburon snapshot (http://indy.fulgan.com/ZIP). The Indy version is 10.5.7 now.
I'm afraid you might just need to trace down into the indy code. Indy has had a number of bugs in the past so this might be the cause. If you trace in you should find it pretty quickly.
Has the IdAttachment.Filename property been set? It's possible that between the Indy versions they changed the way that Filename works.
The recommendations of Richard worked for me. I compared the message sources of a correct attachment and that of Indy. Put the semicolons behind Content-type and Content-disposition (around line 1220 indeed, and it works. Thank you Richard!
Related
Trying to open an attachment with this url and it doesn't work. Any idea why?
https://Blah-apps.com/Development/StrongB.nsf/0/(Attach)/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf!%20&OpenElement
Thanks for any ideas
The attachment was originally created on the web and was an embedded object. I then wrote code to move it to a Rich Text Field and that didn't help. The error I get is
HTTP Web Server: Couldn't find design note
This is from a note that I pulled together for HCL some time ago listing the issues we had with Domino 11 having upgraded from 9. This might help although it is not clear what version you are on.
Broken Download links for LZ1 compressed attachments. - CS0313452
After upgrading to FP5 customers found that they could not download some attachments.
We were able to reproduce this issue 100% and provided HCL with a database.
https://eon.focul.net/eon/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB FoCul determined that this happens to attachments that are automatically compressed with LZ1 even when the database settings do not enable compression.
+SPR# GRHEBVYNW7 - Server - DAOS - Fixed an issue where after upgrading to 11.x,
running dbmt -c on DAOS enabled databases results in duplicate DAOS objects being stored.
This regression was introduced in 11.0.
The URL syntax affected is the old style https://<>//<>/<database.nsf>>/<>/$FILE/<>.jpg
whereas the newer “XPage”style syntax works fine
We modified our applications to use the XPages style syntax as a good work around.
This is the XPages url style
https://acme.focul.net/apps/moc.nsf/xp_f_mod.xsp?action=openDocument&documentId=67BC79B86B06BAFD802582B30042ACFB
Your use of /0/(Attach)/0 looks wrong. Try this format instead: http://host/Database/View/Document/$File/Filename?OpenElement (source: https://help.hcltechsw.com/dom_designer/9.0.1/appdev/H_ABOUT_URL_COMMANDS_FOR_OPENING_IMAGE_FILES_ATTACHMENTS_AND_OLE_OBJECTS.html)
So in your case:
https://blah-apps.com/Development/StrongB.nsf/0/B3B9D4480BEF667C852588310078E1AE/$File/golf.pdf?OpenElement
I have a problem where I am creating an Android app using Firemonkey in Delphi XE6. The app consists of a TWebBrowser and a button...nothing fancy.
I am TRYING to display an xhtml file that is located on my SD card.
I "think" I am doing all the right things like using "TPath.GetHomePath" and putting my file in this location. - and made sure the permissions are set in the project.
Being a seasoned developer, I know that I need to use "file://" so the browser knows it a local file, as I have done a million times in Delphi over the years, and even checking the help file which uses the example "WebBrowser1.Navigate('file://MyFile.pdf')"
So I construct my URL by doing :
AppPath := TPath.Combine(TPath.GetHomePath, 'myfile.xhtml');
I then go:
WebBrowser1.Navigate('file://'+AppPath);
When the navigation happens, it tells me the file doesn't exist, file:///data/data/com.embarcadero.WebBrowser/files/myfile.xhtml
I spotted the 3 /'s i.e. file:/// and thought I would just hard coded the path into a string and got the same problem saying the file doesn't exists and it reverting back to file:///
Can anyone see what I am doing wrong? its got me puzzled thats for sure! :-)
Thanks, Jeremy
Instead of
TPath.GetHomePath
i used
TPath.GetPublicPath
which leads me to /storage/emulated/0/Android/data/<myapp>/files/ folder (the one i need).
TPath.GetHomePath
gives me data/data/<myapp>/files/ which is not exists (i guess, maybe i need something like GetAbsolutePath).
I hope you can solve this or at least tell what to do about it because I'm clueless. The thing is that once I've saved a .wxm file and then want to open it appears on wxMaxima this error and the "app" crashes:
Maxima encountered a Lisp error:
decoding error on stream
<SB-SYS:FD-STREAM for "socket 127.0.0.1:62607, peer: 127.0.0.1:4011"
{13F30991}
(:EXTERNAL-FORMAT :ASCII):
the octet sequence (195) cannot be decoded.
Automatically continuing.
To enable the Lisp debugger set debugger-hook to nil.
Thanks in advance.
P.S.: I run the latest Mac OS X version on my iMac.
Create a new file and write it down.
(setf sb-impl::*default-external-format* :utf-8)
(setf sb-alien::*default-c-string-external-format* :utf-8)
Save the file as .sbclrc at Home (User) folder.
I come back on this post as I have been affected by this today.
I am using Ubunutu 14.04 and the same bug appears. To me it is due to Maxima not being able to load anything else than ".mac" files, nothing to do with utf-8/ASCII (I have mv a file that is working to a wxm and vice-versa, it will not work anymore / rework)
Also I have prepared a workaround:
The idea is too have a tool that translates your .wxm files to a .mac file just before you load it (it is actually a very easy bash script)
So:
you put the wxm-to-mac.sh files into your path
then inside maxima, instead of doing
load("foo.wxm")
you simply do
system("wxm-to-mac foo.wxm")$
load("foo.mac")$
Bare in mind you shall not edit the foo.mac file because a routine might re-erase it afterward. Instead keep editing the .wxm file.
Hope it helps someone
Looks like the file has been saved with some non-ASCII characters (e.g. UTF-8) in it, but it is not read as UTF-8; that seems to be a bug in wxMaxima. Can you please post the offending .wxm file?
I was having the same problem, since none here could give a straight and correct answer (at least is not marked with the green icon) i tried to look somewhere else. I couldn't find an answer that solve my problem, but then i thought that i had used WxMaxima on Mac before and it worked pretty nice. The last time i installed wxmaxima on mac and it worked was in september 2012, i went to the http://sourceforge.net website and searched for the maxima file that was available on that date and i found http://sourceforge.net/projects/maxima/files/Maxima-MacOS/5.18.1-MacOS/, i installed it and its working pretty fine (about the problem, it is weird, even if i create a new maxima file typed "a" and saved it, i could no longer open it, so i'm guessing that it has nothing to do with ascii or non-ascii characters) I have no idea why this error happens on the recent version of Maxima/WxMaxima, but it makes no sense that we have to install a previous version for it to work.
Anyway, it's working for me, and i hope it works for you too. Glad i helped :)
I had the same problem.
In my case, the name of the directory where the ".wxm" file is located, contained Korean letter. I changed the directory name with an English one.
Then the problem has been solved.
I hope this works for you, too.
I have made a form that I use to send a mail using Indy. The form can be used to attach files as well.
All this is working very fine when I use the sample in the link below and when I use it in a utility I have made for sending invoices made as PDF files from an Excel project.
The strange things begin to happen when I put it to use in a large application I have that uses UniDAC and DevExpress - then all of a sudden my Danish chars in emailbody is gone. The are still present in the subject.
I haven't made any changes in the code and the form is executed in the same way as in the sample.
Any ideas as to what I should be looking for in order to get this working?
The sample can be downloaded here:
www.hugopedersen.dk/_guest/sendmail.zip
(some comments and text might be in Danish, but that should have no influence in how the code works)
i wrote a Delphi 5 app that uses TIdFTP. it's been working great for years. it's only purpose is to upload an excel file.
object ftp: TIdFTP
OnStatus = ftpStatus
IPVersion = Id_IPv4
AutoLogin = True
Host = 'somewhere.ca'
Passive = True
Password = 'guess'
TransferType = ftBinary
Username = 'xray'
ProxySettings.ProxyType = fpcmNone
ProxySettings.Port = 0
end
i recently migrated to delphi 2009 since i reloaded my machine and delphi 5 is gone now.
the app still looks like it's working but--most of the way through the 1.5 MB file the file becomes corrupt. it looks like bytes have been deleted and the uploaded file is shorter than the original (by about 200 bytes).
my first thought was the transfer type so i set it to Binary but beyond that, i don't know.
any ideas?
thank you!
mp
What version of Indy are you using? Have you tried the latest one?
Also, did you try with other types of files (plain text, executables...)
A big difference between Delphi 5 and Delphi 2009 is that Delphi 2009 uses Unicode. Maybe you're mixing unicode and non-unicode up? Receiving ASCII, but treating it like UTF8 for example?
like yours, my first thought is that the transfer isn't happening binary ... this seems more likely given your follow-up that changing the file name fixes the problem. do you have a packet sniffer that you can use to follow the ftp conversation? by doing that you'll be able to tell for sure if the mode is being correctly set.
-don
Delphi 5 doesn't have Indy component already installed. So, you have to download it and install it yourself. I never did get it to work. Now, I am using Delphi 7 and it already had it preinstalled. So, I never had a problem with Indy. Its only when I download it for use.