Text Fields not Restored on Load

[jbsound]

I have just spent the better part of a development day trying to figure out why .NET Server will not restore a text field collection from a document.

I have run tests with the TX Text Control Words application to load the same document and everything looks normal there. So it can't be the document itself.

I am using version 12.0.400.500 of .NET Server to create a TextControl object in code, using the myTextControl.CreateControl() method.

Next, I use myTextControl.Load(DocumentData, TXTextControl.StringStreamType.RichTextFormat, LoadSettings) to load the document data into the control.

When I look at the myTextControl.TextFields collection, I don't see any text fields loaded. Again, the document has text fields, which should show up there.

I also noticed that the LoadSettings property BytesRead is 0, which is not the case when loading that same document in Words.

So, the question now is, what I am missing. This is proram code that used to work without any problems with a previous version of .NET Server. Could we have some issues with that specific version?

Thanks for a quick response!

JB

[Gunnar Giffey]

Hi JB,

If you use
myTextControl.Load(DocumentData, TXTextControl.StreamType.RichTextFormat, LoadSettings),
it should work!
If not, please get back to me.

[jbsound]

Hi JB,

If you use
myTextControl.Load(DocumentData, TXTextControl.StreamType.RichTextFormat, LoadSettings),
it should work!
If not, please get back to me.

That is exactly what I am using and it is not working. In other words, the TextFields collection is empty, when indeed there should be items in it after loading the document.

JB

[Gunnar Giffey]

Well, your code was different in your first post, so this was my first idea why it is not working.
Could you verify that the RTF file is actually loaded, e.g. by checking the content of the .Text property?
You stated that "BytesRead is 0", so I would guess that nothing is loaded.
Also, I would like to know how the RTF file was made, did you use TX Text Control to create the text fields?

[jbsound]

My bad, let me check the exact code I'm using in the project. It could very well be in that minute difference that I'm having difficulties with.

Stay tuned...

JB

[jbsound]

Alright, the use of StreamType was specified wrong. After changing it I'm getting a different error.

The document in question has been created with TextControl. That same document would load in Words yesterday. Today, however, Words is also throwing an error, although different than my app.

Here is the error in my application, which is thrown on the myTextcontrolLoad line:

"The path is too long after being fully qualified. Make sure path is less than 260 characters."

That same document in Words is throwing the following error:

"Error in text filter: Unknown format.
(01-1D01)"

Would it be helpful if I would send you the document for your own testing?

The document opens just fine in MS Word.

JB

[jbsound]

A little more information about the mysterious behavior:

The document was created with TextControl.Save(sRTFData, TXTextControl.StringStreamType.RichTextFormat). That is why I was using the StringStreamType, rather than the StreamType.

Using StreamType now seems to be causing the new problem with the 'path' error.

Let me give you more details about the setup here:

I have create an application that acts as an editor to create templates. The templates essentially contain text fields and are stored by the editor application in a SQL table record.

The second application is used by the client's user to create new documents based on these templates. All this just to give you a background.

Here are the differences between the two applications:

The editor application uses the standard TextControl component embedded into a form to display and edit the templates. The templates are saved with the above line and are also loaded back into a 'preview' form with another TextControl component to merge data with the text fields. Using myTextControl.Load(DocumentData, TXTextControl.StringStreamType.RichTextFormat, LoadSettings) will restore the document, plus the text fields just fine.

The user application uses a .NET Server TXTextControl.TextControl instance created in code to load the same document data with myTextControl.Load(DocumentData, TXTextControl.StringStreamType.RichTextFormat, LoadSettings) to get to the text fields and prompt the user with values for the text fields. Then the application merges the data entered by the user with the template and displays the document in a form with an embedded TextControl component.

That is the workflow. So here is what I am seeing:

The template editor application uses only embedded TextControl components and the load mechanism with the above code works fine. No problems. The .NET Server instances created in code seem to have a problem restoring the same document data text fields.

So, the question is why the .NET Server TextControl instance won't load properly with the same StringStreamType format?

JB

[Björn Meyer]

Hello JB

Please provide use your sample document. Are you converting the document (from unicode or similar) after loading it from the database?

Please send me your document directly:

bjoern@textcontrol.com

[jbsound]

Document is on its way...

JB

[Gunnar Giffey]

JB,

Thank you for the document.
I sent you a small demo application, which loads your document and shows all fields correctly.
Could you verify this and get back to me?

[jbsound]

Gunnar,

We finally have it working! Thanks for your help! I think the biggest clue came when looking at the sample app you sent and realizing that for whatever reason (don't ask me :D ) the user application was instantiating a regular TextControl rather than the server control for the loading of the temporary document.

Once that was corrected, everything worked like a charm, including the StringStreamType format use.

So again, in summary for fellow developers:

The problem was that a regular TextControl was instantiated in code rather than a server control. For this implementation we needed the server control instance since we didn't have a visual component associated with it.

There may be a more technical assessment of the summary, but that should do for now.

Thank you for going the extra mile and working with me on the issue! I do appreciate it greatly!

JB

[Gunnar Giffey]

JB,

Good to hear that!
I'm glad that I was able to help you.