ECTL_SETSTRING/ECTL_INSERTTEXT issues

A place where plug-in developers can share their knowledge and experience.
Post Reply
pepak
Posts: 372
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 5 times
Been thanked: 11 times

ECTL_SETSTRING/ECTL_INSERTTEXT issues

Post by pepak » Thu 15 Feb, 2018 07:20

I can't really say these things are bugs, as they are documented, but they still seem strange. Shouldn't we consider changing them?

1) Inconsistency: ECTL_SETSTRING requires that the text be entered in the editor's codepage, cast to wchar (e.g. if my editor uses an ANSI codepage and I want to enter two characters with code 0xab, I need to enter a sequence 0xab, 0x00, 0xab, 0x00). ECTL_GETSTRING always returns its output in UTF16. ECTL_INSERTTEXT expects its input in UTF16, too. Shouldn't ECTL_SETSTRING be modified to expect its input in UTF16 and perform the conversion itself, if needed? The unused Param1 could carry a flag to indicate that this behavior is required, or an ECTL_SETSTRINGEX could be created.

2) Inconsistency: ECTL_GETSTRINGS uses arguments (unused, ptr to structure). ECTL_INSERTTEXT uses (unused, string). ECTL_SETSTRING uses (unused, ptr to structure). Shouldn't ECTL_INSERTTEXT be modified to (unused, ptr to structure) to keep it in alignment with just about every other FarApi call? It would also allow us to...

3) Undesirable behavior: ECTL_INSERTTEXT receives a string as wchar *. That means 0x00 cannot be entered in this fashion. I had to re-implement a 0x00-compatible ECTL_INSERTTEXT using ECTL_GETSTRING and ECTL_SETSTRING, which turns out to be quite a large amount of code which may still cause inconsistencies in the EOL characters. I would very much appreciate it if ECTL_INSERTSTRING also used a (string, length) tuple rather than a simple (string). That's where the conversion of the function to "ptr to structure" from #2 would be useful.

Pepak

User avatar
DrKnS
Posts: 4945
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 164 times

ECTL_SETSTRING/ECTL_INSERTTEXT issues

Post by DrKnS » Thu 15 Feb, 2018 09:15

pepak wrote:
Thu 15 Feb, 2018 07:20
Inconsistency: ECTL_SETSTRING requires that the text be entered in the editor's codepage
Looks like a mistake in the documentation - probably it was copied as is from 1.7.
ECTL_SETSTRING already expects unicode and your example only confirms that.
Shouldn't ECTL_INSERTTEXT be modified
I am afraid it is too late to make breaking changes.
3) Undesirable behavior: ECTL_INSERTTEXT receives a string as wchar *. That means 0x00 cannot be entered in this fashion.
We can extended it with a new flag in Param1 to pass a structure instead, would that be ok?

pepak
Posts: 372
Joined: Sun 13 Jul, 2008 11:18
Has thanked: 5 times
Been thanked: 11 times

ECTL_SETSTRING/ECTL_INSERTTEXT issues

Post by pepak » Fri 16 Feb, 2018 13:04

Extending ECTL_INSERTTEXT would be fine.

Regarding the ECTL_SETSTRING issue, it seems that I was mistaken and the problem was caused by the data I was trying to process.

Post Reply

Return to “Plug-In Developers”