В свое время заморачивался с аналогичной задачей, в результате все было крайне сложно.

Не очень понимаю, чем Вам поможет получение позиции курсора. Обернуть через ORA_FFI SendMessage/PostMessage делов на пару часов (конечно если уметь). Но вот заставить текст вставать туда куда нужно и тогда когда нужно - я очень долго мучался. На Forms 6i проблемы начинались при навигации между item'ами. А в реальном приложении, скорее всего, навигация явная или не явная будет. Если я правильно помню, поборол через таймер: на триггере кнопки /button/ взводил таймер и весь код выполнялся уже в таймере, когда вся не явная навигация в Oracle Forms уже завершена. Было это давно, кода не осталось (или нужно раскапывать старые залежи CD-дисков, вдруг где исходники сохранились ))) )

Другое дело, что у нас приложение было многоязыковым. С поддержкой UTF-8. Возможно, на однобайтных кодировках глюков будет меньше.

Где-то на форуме должен остаться топик с моим матом по данному поводу
andrey_anonymous
Полу правда, полу нет.

1. Окно действительно для _некоторых_ item'ов одно. Но лично мне, это проблемы особой не составляло.
2. Handle окна в Forms 6i вроде добывается стандартным образом, нафига замарачиваться через title, не очень понятно
3. Послать из той же формы можно. Действительно есть проблема с навигацией. Но "если долго мучаться, что нибудь получится" ( C ). По крайне мере я поборол и ушло в продуктив.
4. Через keydown-keyup это, извините, полное извращение. Почему просто через EM_SET_TEXT /вроде так/ для текстовых item'ов не работать? Если нужно нажать на кнопку, все вообще проще.
5. Насчет межпроцессорного взаимодействия, делал, работало. Проблем вообще не было:
5.1. Рисовал прогресс бар. В Forms 6i client-server есть специальный тип User Item. Если его использоваться, можно взять его handle окна и "делай с ним, что хош". Я в нем просто делал свое child окно через WinAPI и стандартным образом (при обработке WM_PAINT) отрисовывал прогресс бар. Собственно тяжелая обработка файлов (нарезания в JTIP граф. файлов с проф. камеры >500-1000 Mb) выполнялась параллельно запущенным EXE'шником. Другое дело, что межпроцессорное взаимодействие (получение %-ов обработки) делал толи через Named Pipe толи просто через стандартные потоки ввода-вывода. Хотя, можно было и через сообщения Windows. Но мне так было проще отлаживать EXE'шник без Forms.

5.2. Делал прием-отправку на сервер графических файлов. Был свой просмоторщик JTIP написанный в виде DLL на MFC запускался в параллельном потоке. Но когда ему нужно было подгрузить очередной файл из БД, приходилось отправлять call back в поток Forms'а с запросом на очередной кусок (что бы работать в сессии Forms'а), поток Forms'а получал файл из БД через PRO*C, отдавал кусок изображения в просмоторщик. Что являлось callback'ом в Forms, уже не помню. Возможно просто кнопка на форме висела и я ее нажимал. Возможно свое child окно в User Item'е. Может даже что-то другое.

Мой мат. В конце приведена работающая последовательность в реальном коде.
http://www.sql.ru/forum/179355/forms-client-server-kak-proverit-chto-item-poteryal-fokus?hl=sendmessage

Если я правильно понял, данный свой топик, то:

Не получилось через ORA_FFI объявить ф-цию SendMessage для вариантов EM_SETSEL и EM_GETSEL - печалька для топик стартера. Если нужно и получать и устанавливать позицию курсора - возможно нужно брать C и делать внешнею библиотеку.

Так же паралелльно нашел еще одну тему:
http://www.sql.ru/forum/777861/vopros-po-cut-region?hl=sendmessage
Похоже, и на однобайтных кодировках в Keep Cursor Position есть проблемы.

Но, в случае, если к проекту разрешено цеплять DLL'ки, задача 100% решается.