12 replies to this topic

[Joseph Bove]

Dear Gang,

Has anyone come up with a good solution for comments entry within ProIV applications? What I am specifically referring to is areas within your application where the end user needs to write a significant amount of comments. Perhaps they need to write a one page description of a conversation.

Here are the solutions that we have considered to date and the pros and cons of each.

Standard ProIV table structure:

FILE: COMMENTS - Autosequenced
K Some naturally occuring key
K Unique Counter
A Comments Text - 75 characters.

The text entry is then done on a paging screen.

Pros: it works, it is fast
Cons: No word wrap, No spell check, awkward for end users

Shelling out to Microsoft Notepad

The comments are still stored in the same table structure. However, all editing is done in Notepad.

pros: Notepad comes up very fast. Word Wrap
Cons: No spell check

Shelling out to Microsoft Word

Same as the notepad approach, but using Word instead

Pros: Spell check, word wrap
Cons: Word is very slow to open, effects done in Word (bold, etc) and not saved back

Using Blobls

We investigated using Blobs and may go further with this. However, there currently is not support for Blobs from ProIV under SQL Server and PostgreSQL.

Pros: All features (bold, etc) can be saved into the database.
Cons: Accessing the information will always require a call to a 3rd party software. Reporting may become a lot tougher.

Using a 3rd Party HTML Product

We have considered this approach. Most of our "good" reporting is being done through HTML anyway. So, saving and retrieving the HTML will likely not be a problem.

Pros: All features can be saved
Cons: Not sure on a good product, not sure if spell check will be supported

The Ideal Solution

Having gone through that history, here are the components that we feel would encapsulate an ideal solution:

1) Must be fast (Word is out)
2) Must support spell check
3) Must support word wrap
4) Would be very nice if it could support bold, italic, etc.
5) Must be supported on SQL Server, PostgreSQL and Oracle

Does anyone currently have a solution that meets our needs?

Thanks for your input,

Joseph

[Chris Mackenzie]

Hi,

Are you using GUI client? Why not write an ActiveX rich text format
control and use it in a P4 screen? On unload, you can take the text,
including embedded formatting, split it into manageable chunks and
store it on the database as varchar2. I tried using the Microsoft one
but ended up having to write that to a file and re-read it which was not
ideal.



That's what we have and it works for us.

[Chris Mackenzie]

...except for the spellcheck.

[Joseph Bove]

Chris,

Yes, we are using the GUI client. We have not started yet on active X. We still develop in native and I don't think that Active X is supported under native.

That aside, how long would you estimate it would take, starting from nothing, to use Active X?

Regards

[Chris Mackenzie]

Using the GUI client, you can run Developer Studio and use ActiveX
and not impact the rest of your app.

Do you have a proficient VB coder - I am told it took 1/2 day to write,
basically it wraps the Microsoft control.

To plug it into Pro-IV, another hour.

Of course you will need some time to get used to DevStudio.

[Kevin Bruss]

What about adobe writer? Same issues w/ word? Could kick off the reader to the appropriate .pdf file.
Just not sure where it would reside; network paths could take up bandwidth, and if on users' drives, they
would potentially get out of synch.

also.. not sure how they are developed, but .hlp files are already in use. perhaps the editor is decent
enough to use.

Edited by Kevin Bruss, 10 March 2006 - 10:00 PM.

[deepghosh]

http://www.thinktech.../think_html.asp

[Joseph Bove]

Kevin,

I think there are some licensing issues with deploying Adobe Writer as a standard solution...

Thanks for the idea though.


Deep,

That product looks nice and reasonably priced for buying the source code too. Thanks for the link.

Regards,

Joseph

[SteveHoughton]

In Single Developer Pro-IV does word wrap in long fields!!

[Joseph Bove]

SteveHoughton,

In Single Developer Pro-IV does word wrap in long fields!!

I think what you'll find is that the word wrapping is limited to 2000 characters. Within the confines of our application, it was too restrictive for our needs.

Thanks for the info.

Regards,

Joseph

[Mike Schoen]

If you do go the route of an external document stored to the database there is a way around the lack of blob support.
We have done this for image scans, where we uuencode the image and store the resulting ascii text in a table.
Displaying it is then a matter of writing the text to a file, uudecoding and displaying.

Note, I did not say this was a nice way around it... <_<

[Joseph Bove]

Mike,

That's an ugly but elegant workaround.

Thanks for posting... I would have never stumbled on that as a solution.

Regards,

Joseph

[Kevin Bruss]

Does the end result/solution have to be in text format? What if you had limited licenses of a editor and generated image files to be used by the users. If text were still needed, it could be added from an oracle table; or better still, search criteria could be embedded in the table to bring up relevant 'image' docs for the user(s).

This gets a bit 'uglier' but easier to maintain if say you store the said images as the uunencoded format and load-on-the-fly for the user in their window(s). That way you don' t have to 'track' the image/data on each person's pc, or god forbid use a network drive to store all the image/data files.

In theory anything is possible; implentation usually will lend whether or not its practical solution..

I'm also thinking there was an old 16bit win-app or something that was used as both a spell checker and calculator combo.. not sure if there's a new version around for xp/pro systems. It used hot keys (w/ ctrl) to bring up a small interface.
Will have to see if I can remember it or find it on some old floppy. heh.

One solution I have seen (but does not account for spell checking/wordwrap) is the usage of 'help' buttons with function IDs as keys to a text table. No pics, but was simple to maintain and local to the system. Users got a 'read only' version of the text of screen-id they were in, and admins could jump into the maint function by screen-id and update the text.

Edited by Kevin Bruss, 20 March 2006 - 08:04 PM.