It just goes to show that this blog describes tips that could just as well be described as 'traps'. Like most of you I try and use tricks that sometimes inhabit the grey zone between what is possible and what shouldn't be done. The interface has several features that allow us ride on existing system behaviour. BUT QA doesn't and can't test for all these things and it can leave us using tricks that although they are safe are essentially unsupported because they are not documented.

Because we sometime use tricks that are not officially part of the APIs we run the risk of adding behaviour that can easily get broken by some change in the code in the eWare.dll.

The above example is such an example. It used to be possible to fool CRM into loading a choosen email template. Like this....

Response.Redirect(eWare.URL(1500)+' &Frame=email &Template='+mergeRecord.emte_id);

The technique was mentioned in passing in this previous article: https://community.sagecrm.com/blogs/hints_tips_and_tricks/archive/2008/12/04/sending-emails-in-asp-com-api.aspx

But...

because of a fix for a bug that happened in Sage CRM 6.1j the querystring information is ignored.

The code behide the action (1500) now goes through a different branch of code that gets the Template value only from the content fields and does not check the query fields so it is ignoring our template value.

Alas there is not a workaround for this I can see.

The general idea of building buttons that redirect to the email editor screen still applies.
https://community.sagecrm.com/blogs/hints_tips_and_tricks/archive/2008/11/10/how-to-build-buttons-that-call-the-email-editor-using-the-com-asp-api.aspx