Earlier versions of the Notes client would automatically turn a sent URL into a clickable link for the recipient (regardless of mail client) but with 6.5 (and presumably later) this no longer happens; that is, the URL is sent as plain text. The Notes UI allows it to be done via the Create->Hotspot->Link Hotspot menu but this gets tedious.
I'm looking for a way to create a Link Hotspot in LotusScript. My research to date leads me to believe that this isn't possible but there may be a hack of some kind.
The automatic conversion of urls into clickable links is a user preference.
In 6.5 it is set via File/Preferences/User Preferences/Basics. In 8 it is set via File/Prefences/Basic Notes Client Config.
I don't think you can create a url link hotspot explicitly using lotusscript. You can create a doc link, but there is no obvious way to turn it into a url link.
You could try an approach where the form is set to render passthrough html on the client and then construct the relevant html for a link.
Update in response to comment.
The scenario is that we want to to control what a user receiving mail sees. We have a few cases we should think about.
The recipient is using Notes and received the mail directly via notes to notes routing.
The recipient is out on the internet using any client and allows email in a rich format.
The recipient is out on the internet using any client and only allows email in plain text.
In the first case the user will see links if they turn on the option for that. You could also create pass-through html in the rich text and that will render on the Notes client assuming the form option is set in the design. If it's straight email and you don't really need any other rich Notes features you could also construct a MIME message.
In the next two cases you just want to send properly formatted MIME messages. In the first of those cases the user will accept rich formatting and therefore you can construct the message as simple html and include links that way. In the second case the user will not, and you have to make do with plain text. Luckily most mail clients will automatically turn urls received in plain text messages into links for you. This may be an option as in the Notes client.
It is best practice when sending rich mail content to also include a MIME section for plain text. That way you don't need to care what version the user prefers.
You need to cheat and create a MIME entry to get your links. Going that route you also can take the opportunity to make it look really nice. The sample code is on this site
Related
I've used the syntax detailed here to access an image from an attachment in another document, and this works. I've also taken the url that is generated and pasted it into a Notes client form as an img src="...". It works there too. However, I can't find a way of finding the port number that XPages in Notes Client (XPINC) uses.
e.g. my URL starts with http://127.0.0.1:64669/xsp/ but the 64669 changes from session to session, and user to user. In the first instance this port was found by examining the URL of the xpage that contained the link, but as I want to do this in a conventional Notes form, I want some way of finding that port number.
Alternatively, if anyone knows a simple way to embed a very small XPage in a Notes client form...?
Second alternative: something along the lines of "Microsoft.XMLHTTP" that will allow the "Notes://" protocol instead of "http://"?
While sending email from lotus notes to Gmail using Lotus Script, buttons are not visible in Gmail.
As Anders says, Any standard or custom Action Buttons (at the top) will not be available in Gmail. You would need to code your own Gmail interface to reproduce.
If you are talking about buttons in the actual rich text of the mail, these will definitely not get translated when the mail leaves and you should get a message saying...
"The following items cannot be sent or saved in MIME (internet mail) format."
That would be a clear sign that you are going to need to take another look at your assumptions.
If you are planning a migration, you do need to check your assumptions (and your vendor's promises) carefully, there is a lot of infrastructure and functionality that is taken for granted in the Notes/Domino stack and just not available, or significantly different, in others.
Stored forms are a feature that is unqiue to Notes. They contain Notes design elements, formulas and scripts that execute Notes functions that are provided by the Notes API DLLs that are only available in the Notes client. GMail doesn't know anything about them. Outlook doesn't know anything about them.
But if you want to send them to someone who has a GMail address but who also has the Notes client, then there is a way to do it manually using the "Send this email to other Notes mail user(s) through the Internet" feature, which appears in the Advance tab of the Delivery Options dialog that you can bring up when sending a message. There is no simple API for automating the mechanism that is used, but it can be done. It requires creating a new empty database file with a special name (encap.ond), saving your document into that database, and then attaching the the file to a new message, which will be the one that you actually send. I don't recall if any special headers are required for this, so if you want to pursue it you will have to do some investigation by using the manual process and checking out the full headers of the message on the receiving side.
This is a very odd issue. When sending a standard email from the iNotes client to a mail in database it will duplicate an exact copy if edited and saved. This behavior does not exhibit itself when editing and saving an email to a notes mail client. The sending mail templates are the current design and the servers are 8.5.3
Has anyone seen anything like this?
Check the design of the mail-in database. Specifically, check the properties of Memo form in the mail-in database, and see if the Versioning property is set to anything other than 'None'. (If you have an agent that is changing the form from Memo to something else, check that form instead.)
Also, turn on the LotusScript debugger, go through the edit/save process, and see what scripts are executed. I seem to recall that some versions of the standard templates used scripts to implement versioning instead of relying on the form properties.
I've got some nice little LotusScript that I can put into the Click event of an Action Hotspot in a rich text field when I'm sending an email manually. Is there a way to programmatically create that in the UI?
My script determines the user's home server and then opens a specific document in the replica of a training database on their home server. I could create these messages with hotspots manually and provide them to the folks who want to email them out. Of course, time being money and the task being boring, I'd rather automate it. I know that I could do this by using a stored form, but am wondering if the greater capability exists, as I can see further applications for it.
One trick I used in the past was to create a profile document in a database, and store some rich text in a field on that profile doc. Then when I needed to programmatically send an email, I could get that rich text field from the profile doc and use AppendRTItem to get it into the body of an email. That should work with any type of rich text, including hotspots.
Note: this won't work in the UI to populate a new email. It does work if you are generating the emails completely in code, though.
I have a form that Legal will use to track trademark claims. They want to be able to attach logos to this for for easy reference. It's easy enough to create a file attachment, but is there any way to show a preview of the attached image?
The solution has to be usable in a browser enabled form.
Attachments are stored in base64 format. You'd need to somehow post that data to the server, encode it correctly, and send it back to the client as a jpg. It's a bit of work, but i'm sure it's doable.
You could add a link column (named preview) to your form library that leads to an .aspx page in the layouts directory, where you read the form xml and generate a preview of the document including the attachment previews.
This way you are able to handle the different attachment formats (e.g using C# code) and bypass the limited functions of the form service.
You could add a "edit this form" button to that page that redirects to the original formservice url.
Most browsers support base64 decoding, so you could very easily just point to the base64 data directly.
You might want to checkout base64 in internet explorer: http://dean.edwards.name/weblog/2005/06/base64-sexy/