Cursor-offset Bug?

[JonMeecham]

If you type using a Russian character set 12345ф7ф (for an english keyboard ф is obtained by pressing the "A" key) into a fill-in using UTF-8 character set and message the cursor-offset in ANY-PRINTABLE you get the following returned.

1
2
3
4
5
6
7
7

See the attached program as an example. NB Windows language/character set must be Russian to get this problem.

Any ideas? ... this is really screwing up my any-printable auto-complete functionality.

Cheers

 

[bulklodd]

Yes, it really looks like a bug. I think it's related to unicode support.
I'd suggest using winapi to get a real cursor position. Here's a snippet:

PROCEDURE SendMessageA EXTERNAL "user32.dll" :
  DEFINE INPUT  PARAMETER hwnd        AS LONG.
  DEFINE INPUT  PARAMETER umsg        AS LONG.
  DEFINE INPUT  PARAMETER wparam      AS LONG.
  DEFINE INPUT  PARAMETER lparam      AS LONG.
  DEFINE RETURN PARAMETER ReturnValue AS LONG.
END PROCEDURE.
 
&Scoped-define SELF-NAME fiChannel
&ANALYZE-SUSPEND _UIB-CODE-BLOCK _CONTROL fiChannel C-Win
ON ANY-PRINTABLE OF fiChannel IN FRAME DEFAULT-FRAME /* Fill 1 */
DO:
    DEFINE VARIABLE iCursorPos      AS INTEGER      NO-UNDO INITIAL 0.
    DEFINE VARIABLE irealpos        AS INTEGER    NO-UNDO.
    iCursorPos = fiChannel:CURSOR-OFFSET IN FRAME {&FRAME-NAME}.
    /* Getting a real cursor offset */
    RUN SendMessageA(SELF:HWND,176,0,0,OUTPUT irealpos).
    /* Extracting the high word from the result */
    irealpos = trunc(irealpos / 65536,0) + 1.
    message iCursorPos SKIP irealpos.
END.

 

[JonMeecham]

Thanks for the reply, although I've tried coding around it using a timer to trigger the code instead of any-printable. This seems to be less buggy.

Upgrading to patch 10B03 seemed to fix some problems.

The last one seems to be setting the cursor-offset for Cyrillic (and other unicode character sets).

Instead I'm having to do this:!!!!!!!!!!!

fiChannel:CURSOR-OFFSET IN FRAME {&FRAME-NAME} = 1.

DO WHILE fiChannel:CURSOR-OFFSET IN FRAME {&FRAME-NAME} < iCursorPos:

APPLY "CURSOR-RIGHT":u TO fiChannel IN FRAME {&FRAME-NAME}.

END.

 

[JonMeecham]

This work around seems to work.

Uses SET-SELECTION with the start and end position the same!:lol:

fiChannel:SET-SELECTION(iCursorPos, iCursorPos).

 

[bulklodd]

I just misunderstood your aim.
I supposed you just wanted to get the cursor offset in a fill-in.
Anyway now I've got many workarounds to get/set the cursor offset

 

[JonMeecham]

You were correct with my first aim to query cursor-offset correctly. The problem wasn't happening on a colleagues environment so I upgraded to same patch level and querying was find.

Setting the cursor-offset still doesn't work :awink: which is why I tried the set-selection. You gave me the idea with your sendMessage call since there is also one for setting selection with the EM_SETSEL (instead of EM_GETSEL) parameter.

Progress should ideally be using this API internally to get/set the cursor-offset but obviously they're not!

Thanks for the help.

 

[bulklodd]

Progress should ideally be using this API internally to get/set the cursor-offset but obviously they're not!

I think they certainly use API they can't avoid using it but indirectly. I suppose there's a such thing like Progress Foundation Classes over API but I don't know exactly

 

[bulklodd]

As you've already mentioned the problem is fixed in 10.0b03.

Here's a quotation from the release notes:

20050804-006 Internationalization The cursor-offset attribute for fill-ins
does not work correctly with multi byte
characters when using -cpinternal UTF-8.