Extended character bugs

MacOSX and iOS
1

I’m pretty sure I reported this before and it got fixed, but it sesems to be broken again.

On the mac, you can’t type ü (and other characters), but you can paste them into text boxes.

Also if I use File::findChildFiles() and a file with a ü is returned and i do a drawtext it shows up as a square box. However, if i paste a ü into a text box, it shows up fine. So juce can print the characters fine. I can also access the file just fine, so the filename is intact.

in the following picture you can see the difference between typing ü and pasting ü

in the following picture you can see the ü is missing from the filename, just shows up as u.

2

We have same problem with Japanese input method. Also Chinese and Korean must have the same problem. And it is too hard to explain… :cry:

Masa

3

Ok, chaps, it looks like the key entry stuff was a bit old and needed updating. Have a go of this tweak and see if it sorts things out:

[code] OSStatus handleKeyEvent (EventRef theEvent)
{
updateModifiers (theEvent);

    UniChar unicodeChars [4];
    zeromem (unicodeChars, sizeof (unicodeChars));
    GetEventParameter (theEvent, kEventParamKeyUnicodes, typeUnicodeText, 0, sizeof (unicodeChars), 0, unicodeChars);

    int keyCode = (int) (unsigned int) unicodeChars[0];

    UInt32 rawKey = 0;
    GetEventParameter (theEvent, kEventParamKeyCode, typeUInt32, 0, sizeof (UInt32), 0, &rawKey);

    if ((currentModifiers & ModifierKeys::ctrlModifier) != 0)
    {
        if (keyCode >= 1 && keyCode <= 26)
            keyCode += ('A' - 1);
    }

    static const int keyTranslations[] =
    {
        122, KeyPress::F1Key, 120, KeyPress::F2Key,
        99, KeyPress::F3Key, 118, KeyPress::F4Key,
        96, KeyPress::F5Key, 97, KeyPress::F6Key,
        98, KeyPress::F7Key, 100, KeyPress::F8Key,
        101, KeyPress::F9Key, 109, KeyPress::F10Key,
        103, KeyPress::F11Key, 111, KeyPress::F12Key,
        36, KeyPress::returnKey, 51, KeyPress::backspaceKey,
        123, KeyPress::leftKey, 124, KeyPress::rightKey,
        126, KeyPress::upKey, 125, KeyPress::downKey,
        115, KeyPress::homeKey, 119, KeyPress::endKey,
        116, KeyPress::pageUpKey, 121, KeyPress::pageDownKey,
        76, KeyPress::returnKey,
        0
    };

    const int* kt = keyTranslations;

    while (*kt != 0)
    {
        if ((int) rawKey == *kt)
        {
            keyCode = *++kt;
            break;
        }

        kt += 2;
    }

    switch (GetEventKind (theEvent))
    {
    case kEventRawKeyDown:
        keysCurrentlyDown.addIfNotAlreadyThere ((void*) keyCode);
        handleKeyUpOrDown();
        handleKeyPress (keyCode);
        break;

    case kEventRawKeyUp:
        keysCurrentlyDown.removeValue ((void*) keyCode);
        handleKeyUpOrDown();
        break;

    case kEventRawKeyRepeat:
        handleKeyPress (keyCode);
        break;

    case kEventRawKeyModifiersChanged:
        handleModifierKeysChange();
        break;

    default:
        jassertfalse
        break;
    }

    return noErr;
}[/code]
4

That fixed the input problem for me. Thanks.

I’m still looking into the filename problem, I’ll let you know if I figure anything out, I’m not much of a mac programmer. I think it has something to do with the conversion from utf8. Maybe the character set needs to be changed or something.

5

What happens if you print the filename to the stdout? Could it just be that the font doesn’t contain that character, and the mac font stuff is substituting a normal “u”?

6

Using JUCE 1.38, I created a little test app that has a FilenameComponent, and when the filename changes it prints out the filename in hex and the file contents in hex.

I created a file named dück

If I browse for the file I get: 64 75 308 63 6b

If I paste the filename in I get: 64 fc 63 6b

Both filenames allow me to access and open the file:

The contents of the file is also dück (Windows Latin) is also dück and it prints as 64 fc 63 6b

#include "../jucedemo_headers.h"

class TextDemo : public Component, public FilenameComponentListener
{
public:
	TextDemo()
	{
		setVisible(true);
		addAndMakeVisible(fc = new FilenameComponent(String::empty, File::nonexistent, true, false, false, T("*"), String::empty, String::empty));
		fc->addListener(this);
	}
	
	~TextDemo()
	{
		deleteAndZero(fc);
	}
	
	void filenameComponentChanged (FilenameComponent* fileComponentThatHasChanged)
	{
		repaint();
	}
	
	void resized()
	{
		fc->setBounds(5, 5, getWidth() - 10, 30);
	}
	
	void paint(Graphics& g)
	{
		File f = fc->getCurrentFile();
		
		String s = f.getFileName();
		String o;
		for (int i = 0; i < s.length(); i++)
		{
			o += String::toHexString(s[i]) + T(" ");
		}
		g.drawText(o, 5, 50, getWidth() - 10, 30, Justification::topLeft, false);
		
		if (f.existsAsFile())
		{
			s = f.loadFileAsString();
			String o;
			for (int i = 0; i < s.length(); i++)
			{
				o += String::toHexString(s[i]) + T(" ");
			}			
			g.drawText(o, 5, 70, getWidth() - 10, 30, Justification::topLeft, false);
		}
	}

private:
	FilenameComponent* fc;
};

Component* createTextDemo()
{
	return new TextDemo();
}
7

I think this is the root of the problem:

http://developer.apple.com/qa/qa2001/qa1173.html

On another note, I also have my LocalisedString files in MacRoman, which no longer seems to work either. I got boxes for all extened characters.

Is juce using a Latin character set internally?

8

Ok, the decomposed/composed character stuff is all news to me. I guess I just need to make it compose the string before it gets drawn to the screen, though it all seems very complicated…

The default char* to unicode conversion is just to use mbstowcs(), which I guess depends on the locale. Might be safest just to save the localisation files as unicode rather than 8-bit, so there’s no danger of a mix-up.

9

offtopic, don’t kill me i just had to

[quote]
On another note, I also have my LocalisedString files in MacRoman, which no longer seems to work either. I got boxes for all extened characters. [/quote]

hey my name is Roman and i have a MAC, does that make me
MacRoman ?