Paul: Thanks for the response. I asked: "/Can we turn off that /[Unicode]/ detection, thus eliminating Unicode processing?/"
You replied: "/No, this has been asked several times on the list, it's part of the internal processing that LC uses and is too deeply embedded to eliminate/". I have been watching this forum for many moons, but usually don't have much to say. I have seen MANY questions asked about whether an option was available to turn off the Unicode "feature". I have seen the responses, all of which were negative. OK, fine. LC7 can't live without Unicode. If Unicode is what's behind the performance glitches, then that's most certainly not the answer I want to hear. But, life goes on. My question arose from Dr. Brett's claim that "/the LC7 engine only uses Unicode if it has to/". That was news to me, and it made it sound to me like the engine was somehow detecting Unicode being used. That's why I asked if we could disable that detection, and thus effectively disable Unicode processing. I envisioned a bazillion places in the engine's code where it might say "If gUnicodeGlobal is true then ... else ...". I hope there aren't a bazillion places where the engine determines it has to use Unicode, because that would require a bunch of needless CPU cycles that could be reduced to referencing a single global (like above). Perhaps my logical view of the situation was incorrect, but I (we) can hope, right? re: "/this sounds like the type of case that the engineers are asking to see/" Agreed. That sounds like the next step in the resolution of "my" problem. But, none of them responded, so I got the feeling they weren't interested. If they need some example data, I can spend the time to extrapolate some records during a test run within the IDE. However, the explanation of concatenating native strings to a few binary bytes should give them enough info to say "yes" or "no" about the engine's detection of Unicode ... which I hoped could be turned off, so no matter what info I use would bypass the Unicode processing. If that's not the case, then ... ... we're back to square one, meaning I/we have to live with Unicode's performance issues. I'm wondering how a feature like Unicode that has had a major performance impact managed to get past the initial design stage, but that's a different issue altogether. Surely somebody, somewhere foresaw this "enhancement" would be a major resource hog. TED -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690262.html Sent from the Revolution - User mailing list archive at Nabble.com. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
