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)
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 am writing a Program in Rub On Rails 4.x and I have to take PDF files with defined fields that can be filled out, fill in data from a form submission(This part is DONE!), and lastly allow the user to modify the saved PDF file on the server and overwrite said PDF after making their modifications.
Like I said I have already gotten the PDF files filled out with what has been submitted in the form through pdftk . What I now need to do is provide a server side editing capability to the said PDF files on server generated from the first step of the process.
I have seen similar posts but none wanting to do the same thing I do. If I am wrong links would be great. Thanks in advance for all your help!
After lots of digging and research here is what I have found to be the facts surrounding this issue and implementing a program to allow embedding the PDF file, editing it, and saving it back to the server. This process would be great however from what I can tell there is nothing out there that really does this for Ruby On Rails. To quote #Nick Veys
Seems like you need to find a Javascript PDF editor you can load your PDF into, allow the user to modify it, and ultimately submit it back to the server. Seems like they exist, here's one for ASP projects
You are correct but still wrong in the sense that yes there is one for ASP projects however that is Microsoft Based, yes I know that it can run on Linux environments through Mono. However to the point it would appear in this instance that a Ruby On Rails specific solution is indeed needed.
The solution that we have come up with is as follows
1. Use a PDF editing package in the linux repositories like PDFtk
2. You then render a page with the PDF embeded on one side and a form representing the live fields in the PDF to take input.
3. Once submitted you use PDFtk to write the values into a new template PDF file and overwrite what was previously stored.
This requires a few additional steps to process the data than I really care for myself. However it is the best solution that our team could come up with, without bleeding the project budget dry for just 1 piece of functionality.
I hope this helps anyone else looking to do the same thing in Ruby On Rails.
I have done something like this using my company's .NET product. It can also be done using its Java version too.
http://www.gnostice.com/nl_article.asp?id=255&t=Save_Form_Submit_Data_Back_To_Original_PDF_Document_In_NET
I recently upgraded to Excel 2010. I was working on a spreadsheet and wrote some code and went to save it and I get this box that pops up. I'm not sure what to do.
From Office 2007 on, Excel has two different file types: XLSX and XLSM. The former is just data and formatting without macros or anything "dangerous." The latter allows macros and other programmatic functionality. The reason for the split is mainly security as each one has a distinct extension and icon to better inform the user on whether or not the file could potentially contain dangerous content.
In this instance, you need to click No, then in the Save As... options select "Excel Macro-Enabled Workbook." That will give you the full functionality of the original document.
What I do now with Outlook:
I receive email orders for products. I select a single or multiple emails in Outlook (a single order can have multiple emails associated with it) and then switch to my Delphi coded OrderManager program and click "Import". It uses Outlook's COM automation interface to read the text of each message, parses and processes each one.
The question is, can I do this using Thunderbird instead? Does Thunderbird have a COM interface? I must be googling the wrong keywords because I haven't found anything yet.
Btw, I do have a version of my OrderManager that just reads the emails directly from my email server using Indy, but for several reasons I'd like to try to read them from Firefox.
Any suggestions, links to docs, or code samples will be greatly appreciated!
Check this link out.
You could write a C or C++ wrapper around XPCOM and then use that wrapper within Delphi.
There is also an open source XPCOM wrapper written in Delphi. You might want to check that out as well. Thanks Stijn for pointing that out.
Hope it helps.
You could also parse Thunderbird's mailbox files yourself.
From %APPDATA%\Thunderbird\profiles.ini, read where the profile folder is located (if there's more than one profile, look through sections Profile0..Profilen for the one that has the value Default=1)
Each subfolder of the Mail and/or ImapMail subfolders of the profile folder represents an account (Mail contains POP accounts, ImapMail contains IMAP accounts);
Look through all files whose names don't end with .dat or .msf, and whose contents start with 'From ' (F, r, o, m, and a space). Those are the mailbox files.
Every line that starts with 'From ' indicates a new message. Use the X-Mozilla-Status header to figure out whether the message is still valid, or whether it's been marked for deletion. (You can use the CDO.Message COM object to parse the message for you, if you want).
You should recurse for each subfolder ending on '.sbd', since that will contain that mailbox's subfolders (E.g. Inbox.sbd will contain the mail folders under the Inbox).
Be wary of file locking issues, however.
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!