Blogged by Björn Meyer on August 28, 2008 and tagged with Adobe PDF, Survey.
Our R&D team is currently gathering some information for future developments and products. One very interesting field is the import of Adobe PDF documents.
The intention of the PDF format is to view or print documents in various platforms and applications. Sometimes, documents are stored in the PDF format without saving it's original format such as MS Word DOC, RTF or DOCX. PDF documents can't be easily imported like these word processing formats. Converting PDF documents back into a format that can be edited using a WYSIWYG editor is a very complex task.
To help our engineers, we would like to ask you about your thoughts and your experiences. We would greatly appreciate it if you could help us by completing the following survey. It takes you less than 2 minutes.
Start now:
http://www.textcontrol.com/surveys/pdf.htm
Thank you very much for your help.
Blogged by Björn Meyer on August 15, 2008 and tagged with .NET Server, Mail merge.
With version 14.0 of TX Text Control .NET Server, we introduced a complete new namespace: TXTextControl.DocumentServer. This namespace contains best practices for specific and typical server-side document service applications.
A common server-side application is template-based mail merging. This allows developers to merge templates with database content. A template consists of merge fields that can be bound to database fields. TX Text Control .NET Server provides additional functionality to build sophisticated mail merge applications.
A template that can be loaded into the MailMerge component can contain two different types of fields: General fields that are part of the main text and fields that are part of a merge block. Merge blocks are repeated based on the number of data rows in a given DataSet. The block is acting like a sub-report with a separate set of data values.
The following diagram shows the idea behind these blocks:
The merge block consists of a number of merge fields. For each data row of the passed DataSet, all fields in the block are merged with the given data of the current row. Additionally, the BlockRowMerged event is fired when a complete block is merged. In the event arguments of this event, the merged block is returned as a byte array in the internal TX Text Control format. This allows you to change the content of a merged block row. This approach can be used, for example, to change the background color of a table row to realize alternating table row colors
Another event is fired when the complete template has been merged. This allows you to save the document into a file when the append parameter of the Merge method has been set to false. In this case, the resulting documents are not appended to the same document.
Using the following code, you can load a template into the MailMerge component:
mailMerge1.LoadTemplate("template.docx", TXTextControl.DocumentServer.FileFormat.WordprocessingML);
The Merge method is called to merge all fields in the template that are not part of a merge block:
mailMerge1.Merge(mergeData, true);
To pass the data for the blocks, the MergeBlocks method must be called. The passed DataSet must contain a DataTable for each block in the template. The name of the block must be the same as the DataTable name:
mailMerge1.MergeBlocks(mergeBlockData);
Each time a block row is merged, the BlockRowMerged event is fired and can be used as shown in the following code example. The returned byte array is loaded into a ServerTextControl instance for further processing. The changed document can be passed back to the e.MergedBlockRow property:
void mailMerge1_BlockRowMerged(object sender, TXTextControl.DocumentServer.MailMerge.BlockRowMergedEventArgs e)
{
byte[] data = e.MergedBlockRow;
serverTextControl1.Load(data, TXTextControl.BinaryStreamType.InternalUnicodeFormat);
}
Finally, the document can be saved in one of the supported file formats. The next two code lines save the merged document as an Adobe PDF document:
TXTextControl.SaveSettings sSettings = new TXTextControl.SaveSettings();
mailMerge1.SaveDocument("results.pdf", TXTextControl.StreamType.AdobePDF, sSettings);
The next illustration shows the complete MailMerge class and it's properties, methods and events. It gives an overview of the possibilities using the MailMerge component.
Try that on your own by downloading the TX Text Control .NET Server trial version. It comes with a complete set of sample projects for Visual Studio 2005 and 2008 that shows the different functionality of our MailMerge component.
Download TX Text Control .NET Server Trial Version
Blogged by Jonathan Maron on July 24, 2008 and tagged with Service Pack.
Today, the following service packs were released:
- Service Pack 2 for TX Text Control .NET Server 14.0
- Service Pack 2 for TX Text Control .NET 14.0
- Service Pack 2 for TX Text Control ActiveX Server 14.0
- Service Pack 2 for TX Text Control ActiveX 14.0
Please take a look at the updated known issues list at:
http://www.textcontrol.com/support/issues/
You can download the service pack at:
http://www.textcontrol.com/downloads/sps/
As ever, our support team is waiting to answer your questions. Full contact details at:
http://www.textcontrol.com/support/
Blogged by Björn Meyer on July 17, 2008 and tagged with Visual Studio, Microsoft, VSIP.
Yesterday, we received the acceptance letter from Microsoft® stating that The Imaging Source® is now officially listed as a partner company.
By joining the VSIP program, The Imaging Source continues the persistent commitment to our customers to provide tighter integration between TX Text Control® and Microsoft Visual Studio® .NET 2005 and 2008. This partnership allows us to provide an unprecedented Visual Studio integration and guarantees compatibility in future versions of Visual Studio and TX Text Control. We are now one of more than 200 industry market leaders that have joined this program to provide better products for Visual Studio.
Blogged by Björn Meyer on July 11, 2008 and tagged with Sample, .NET Server.
When building a browser-based word processing application using TX Text Control .NET Server, the BrowserTextControl is wrapped in a Windows Control Library. This provides many advantages including the fact that most of the functionality can be wrapped in the user control and must not be implemented from outside using Javascript or any other client-side scripting language.
However, we are building web applications! Today's web applications are built using client-side scripting for different purposes like an AJAX implementation or the client-side communication between different integrated controls.
By implementing the events in the wrapper control, you can trap them inside of the control that is isolated in the web page. The browser is not able to access these events, though.
But trapping such an event using client-side Javascript could be really helpful. Consider the following example:
You implemented a function to save the content of the BrowserTextControl to post it to the server using HTTP POST like described in our documentation. This client-side call should be triggered by the wrapper control when the user clicks a specific button or menu entry. On this action, the wrapper control should fire an event that can be trapped client-side using Javascript to call the implemented save function.
Sounds good! But how to implement that?
Due to an article in the asp.netPRO magazine from Steve C. Orr, an expert I hold in great respect, it is not possible to raise events back to the page:
BTW: I honestly recommend to read this article completely, it perfectly describes the methodology behind this technology.
"[...] Another issue is that communication between client-side script and Windows controls is currently one-way only. That is, JavaScript functions within the page can call methods of the hosted Windows control, but the Windows control cannot raise events back to the page. [...]"
From what we have learned above, this statement is true. Anyway, there is a way to get around this catch-22 situation.
The Internet Explorer accesses the Windows Control Library properties and methods using the implemented COM interface that enables Internet Explorer to execute client-side controls like ActiveX controls, Flash players or our .NET assembly. This doesn't imply that this approach uses COM or ActiveX technology. The Internet Explorer simply uses the existing interface to handle everything that is between <OBJECT> and </OBJECT>. This is the reason why the 'Make assembly COM-Visible' checkbox must be checked in the assembly properties.
To implement a public COM-visible event, it is required to create a COM-interface in the wrapper control:
[ComVisible(true), InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface BrowserApplicationEvents
{
[DispId(0)]
void SaveDocument();
}
This visible interface enables the client-side Javascript to trap our events. Then you need to identify a list of interfaces that are exposed as COM event sources in your wrapper class:
[ComVisible(true), ClassInterface(ClassInterfaceType.AutoDispatch), ComSourceInterfaces(typeof(BrowserApplicationEvents))]
public partial class BrowserAppControl : UserControl
{ ... }
The event itself can be implemented to any event in .NET:
public delegate void SaveDocumentHandler();
SaveDocumentHandler saveDocument;
public event SaveDocumentHandler SaveDocument
{
add { saveDocument += value; }
remove { saveDocument -= value; }
}
protected virtual void OnSaveDocument()
{
SaveDocumentHandler handler;
handler = saveDocument;
if (handler != null)
saveDocument();
}
This event is now publicly accessible for client-side scripting languages:
<script for="BrowserApp" event="SaveDocument" language="javascript">
alert("In Javascript client-side event, you can call the client-side save method.");
</script>
Feel free to contact me, if you would like to learn more about this approach.
Download the sample code here
Archive
