4 replies to this topic

[jbach35]

I'm hoping someone has made some progress in regards to spell checking and word wrapping text fields.

I have done the requisite searching here but only found a few suggestions.

We currently have 2 solutions tested and implemented, each with their positives and their drawbacks.

One is to shell out to Word on the local PC (running a GUI client) and the other is to run a java servlet application (developed in house) that displays a simple "text editor".

I've seen mention of wrapping around Notepad or using a help file editor, among others.

We really wish to stay inside of our Pro-IV program to ensure a secure environment and maintain our auditing of @OPR, date, and time stamping.

We are currently on v5.5 r411, and migrating to r543, and will be moving on to v6.x within a year or so.

I'd like a solution that will work in 5.5 r411, and migrate up too.

Does anyone have a solution?

I even like the way this forum works.... I've used ieSpell before, but I'd need a way to implement the php script to display the text box.

While I appreciate suggestions and tips, it is not outside our scope to pay for code that is currently working that satisfies our needs.

Regards.

Jon

Edited by jbach35, 15 March 2009 - 03:58 PM.

[gdmjdkc]

We are using a 3rd party Active X control spell checker "Wspell" by Wintertree Software together with the Microsoft Rich Textbox Control 6.0 (SP4) Active X control provided in ProIV. This solution is easy to implement and the licensing for Wspell is quite reasonable. I just looked at the website for Wspell and a Site License is $1900.00.

We did need to modify the Rich Textbox provided by ProIV. We made the changes by writing an additional wrapper around it exposing some properties needed at design time. ProIV does not support run time properties and one of the controls needed is the veritcal scroll bar. The only way to turn it on in ProIV is at design time.

You can link the spell checker to the rich text box control by use of the hwind property with only a few lines of code. The example below is the code that moves the data into the spell checker shows the corrections as they are made in the RTF control and moves the data to a variable then calls the update cycle to actually write the data to the table.

EditX.MaxLength = 500
$HANDLE = EditX.Hwnd

#SPELLSTART = 0
EditX.HideSelection = FALSE
WspellX.ShowContext = FALSE
WspellX.IgnoreCapitalizedWords = FALSE
WspellX.IgnoreMixedCaseWords = FALSE
WspellX.TextControlHWnd = CONV($HANDLE)
#SPELLSTART = WspellX.Start()
$STRATEGIES = EditX.Text
LSCALL("WriteStrategies")

This would meet your requirement to stay inside of ProIV for your needs. We have been using this solution for almost 5 years now with very good results. The "Wspell" control has performed flawlessly.

[jbach35]

Thank you for that information.

I have several more questions (sorry )

Are you using Cisam files?

How is the text stored and displayed later?

Do you import the text into a ProIV file?

We currently format and save the Word document as a text file by running a macro, then import it into our application by reading each line (within a loop) and write each line to a field 70 characters long.

Would using blobs be an alternative?

Does ProIV still only supports the storage and handling of blobs via the DB? or does it have a data type of blob available for field use.

Jon

[gdmjdkc]

Are you using Cisam files?
We use Sql back end.

How is the text stored and displayed later?

The text is stored in a character field. The drawback is that ProIV limits the length of a field to 2k. Actually 1950 characters. For our process this is sufficient although in a couple of instances it would be nice to have more.

Do you import the text into a ProIV file?

Again we use SQL for data storage.

We currently format and save the Word document as a text file by running a macro, then import it into our application by reading each line (within a loop) and write each line to a field 70 characters long.
We use Crystal Reports for output of documents. We bypass ProIV for this process and hook Crystal directly to SQL. We do have an active X control in ProIV that passes parameters to Crystal and displays the output inside ProIV. Crystal takes care of all formating and output need. We allow output to a printer or PDF. Several other output methods are available from Crystal, but we limit the user choices pragmatically.

Would using blobs be an alternative?

Does ProIV still only supports the storage and handling of blobs via the DB? or does it have a data type of blob available for field use.
ProIV does not support blobs at least not in 5.5 (that may change in version 6). I know the documentation says they do, but when we were attempting to use blobs early on in our project we found that they really do not.

If you are needing to write large documents this may not work for you. Our process is such that we have several small notes that make up a larger document. I have made attempts at parsing the data in and out of the spell checker and ProIV, but have not had any luck with the results.

I have however had luck with doing spell checks on the ProIV text boxes with Wspell. It is not interactive like it is with the RTF control, but Wspell does have it's own window to display the text as it is checking. (WspellX.ShowContext = FALSE) Setting this property to True will display the text in the Wspell window. Using the ProIV text box may allow you to parse the data. To use Wspell with a text box you would need to pass the text in a variable since the Hwind property is not available.

I hope this answers some of your questions.

[jbach35]

Thank you (again) for your help.

This does answer a lot of questions.

Our clients often write several page reports, as many as 5000 to 10,000 lines of text.

We don't have any plans on using Sql or Crystal at this time.

I guess our next project is trying simulate a word wrap feature in Pro-IV that works in gui. We have one that works nicely when using character based mode, but we're trying to get away from those terminals.

I've found some fairly inexpensive "spell as you type" programs that seem to work ok... at least during initial tests, but they only check the current field you are in.

SAYT is a decent partial solution, but there is no way that I can see to check the whole report as each line typed is it's own field.

I guess we could define 2k long text fields, polish up our word wrap, then the document would "appear" to be one contiguous report, and spell checking each field would seem like it's checking most of the report (in 2k segments).

I will look into the idea of using Wspell to check the 2k ProIV fields too.

Jon.