See https://github.com/tempelmann/custom-editfield
Thanks to Stphane Mons, it finally works with Dead Keys when building for Cocoa.
Just curious… I am assuming nothing more has been done since version v1.8.2 (released 19 Mar 2017) ?
It still has a ton of Cocoa calls (most of which I figured how to replace.)
but the biggest issue… it runs fine in 32bit mode… but really gets wacky in 64bit (text is rendered totally wrong etc.)
I know this is based on Alex Restrepos (?) work from way back when… but I don’t need all the FTC (for example) offers, and have limited $$$ to boot (heck I’m saving up to get Xojo2018 as it is 
)
It’s at v1.8.7 now and should have improved for 64 bit, too. For change notes, see https://github.com/tempelmann/custom-editfield/commits/master
@Dave S: it works really smoothly in 64-bit (except code folding) and it is free as far as I know
Have you submitted the changes for inclusion?
- Still has over 20 Carbon references
- No… because the version I made didn’t work in 64bit, and DEAD KEYS was one of the things I had to strip out… but it is also one of the latests “fixes”. DblClickTime replacement was easy. And NewCGImage was “easy” as what was there wasn’t working anyways (even in 32bit), and the same I believe for drawFocusRing
then it would still have 64bit issues then ,
Like I said… I’d used CEF for years… and actually made a large number of contributions in the past (for which my credits seems to have been removed at some point [no worries])
I’d found a lite-weight alternative, but this morning realized it didn’t have UNDO or Code Folding … but I have to decide, as the app I want to use this in is already a heavy-weight in its own right.
@Dave S:
Dead key: the dead key problem was fixed a long time ago for Cocoa (by me actually)
Carbon calls: many Carbon calls are still valid in 64-bit and complementary to Cocoa calls. They are not inherently bad.
Of course I do not want to force feed you with CEF, but maybe you could give it a new try
my understanding is that Cocoa is 32bit therefore would be useless after Mojave
I don’t want to make a huge investment in time, for a limited life cycle… not to mention that an example I tried totally managed the text when compile in 64bit, and worked fine in 32bit… While to a certain point I consider my time to be “free”, I also want to see forward motion… and the monetary return I expect from the finished product doesn’t warrant me gambling what little funds I have on a paid component
@Dave_S: which PAID component? CEF is free, as far as I know
I realize that… my point was … if CEF won’t work (and 64bit is an issue), I cannot afford to PAY for an alternative (like FTC for example)
And as I also said. I have used CEF since Alex was still actively involved… but then Retina and 64bit were not issues
So again. for future proofing … CEF doesn’t work for me
- Doesn’t work for 64bit (regardless of what you may say)
- Contains Carbon, which will fail with next macOS after Mojave
- Contains graphics that are not Retina compatible (although that is easy to change)
So… since this conversation is going in circles… I will find something (or make something)
Thank you
Well this is the first CLEAR message you sent and NOW I understand, though I still think that some of your criticism were made in bad faith.