DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature I have checked the new Mac OS patch. I see that all character composition sequences work well, as does character palette input. I am however concerned that the changes introduced in functions setMarkedText and insertText hinder the present text input capabilities of FLTK. Presently, it is possible to use with FLTK1.3 the "Pinyin - Simplified" input method of Chinese characters, to some extent at least. If you activate this method, and type li <space> wu <space> luo <space> you'll obtain these three Chinese characters ç«æ ç½, the same as you would obtain if you type the same sequence in, say, TextEdit. With the patch, the result is unpredictable, that is, not reproducible. This is because there is a memory allocation problem in these statements: Fl::e_text = (char*)[received UTF8String]; and Fl::e_text = (char*)[aggregate UTF8String]; After them, Fl::e_text points to a memory location that can become reused as soon as the "received" or "aggregate" NSString objects are deallocated, that is, some time after return from the functions where these objects are defined. I propose a modified version of your patch that handles both character composition and the small part of CJK input that's already supported (see fltk-1_v4.3.x-dead-chars-mac.patch). Also, I don't understand why you build Fl::e_text in setMarkedText as the concatenation of the previous Fl::e_text and the received string. Besides the fact that the memory allocation in there is very problematic, I don't see why there's need for a concatenation. Are there cases where more than one character is a dead key in character composition under Mac OS ? Thus, please, test the modified patch and post if it does not cover some character composition cases. I would also suggest that you put the cocoaDead2FLTK function in your application code rather than in FLTK itself. Indeed, there are many more dead keys than the five considered by this function. Thus, it's a feature of your application to take care of these five only, rather than a feature of the application-neutral FLTK library. Do you agree ? I have also added a couple of missing fl_lock_function() / fl_unlock_function() pairs of calls. Link: http://www.fltk.org/str.php?L2599 Version: 1.3-feature
_______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
