Calling your own editor from a form

Has anyone written a user-exit or Pro*C program to do the following: when a user hits the edit key on a field (in my case, a field of the LONG data type), call your own editor, such as vi? I have an idea of how I should do it, but I'd like to know how other people have done it and what pitfalls you might have run in to.

This is what I'm thinking of right now:

• when user hits the [edit key], host out to a shell script.
• the shell script will take as a parameter the primary key of the record that contains the LONG field to be edited. It will call a Pro*C program that checks if the LONG is not null. If it is not null, it will dump the contents to a file named <primary_key>.$$ or some such ($$ might have to be part of the parameter passed to the Pro*C program). If it is null, it does nothing.
• the shell script will read the EDITOR environment variable and call that editor, defaulting to vi if EDITOR hasn't been defined. It will call the editor on the <primary_key>.$$ file. If there is no such file, as in the case where the LONG field was null, the file will be created when the editor is invoked.
• The user is now in the editor, typing away.
• When the user quits out of the editor, the shell script will call a Pro*C program that takes the <primary_key>.$$ file as a parameter to read in that file and put it back into the LONG field.

We're using Pro*C to print out the contents of the LONG field in most reports, but I think we have a few Reportwriter reports as well. Will Reportwriter handle the carriage returns correctly, printing them where the user intended them to print?

Please mail me directly at "alicel_at_sco.com", as I don't get the time to read news that often. I will post anything I receive if it looks helpful.

Thanks,

-alice Received on Tue Aug 23 1994 - 05:27:33 CEST