Injecting text in TextBox manually

I've got a setup where you can just start typing and that text should be captured to the main_input TextBox. There doesn't appear to be a clear interface to do so. So I looked at how GUIManager handles it and wrote something like this.


if (!mGUIManager->injectKeyDown(static_cast<QuickGUI::KeyCode>(arg.key))) {
QuickGUI::KeyEventArgs args(main_input);
args.scancode = static_cast<QuickGUI::KeyCode>(arg.key);
main_input->fireEvent(QuickGUI::Widget::EVENT_KEY_DOWN,args);

QuickGUI::KeyEventArgs args2(main_input);
args2.codepoint = arg.text;
main_input->fireEvent(QuickGUI::Widget::EVENT_CHARACTER_KEY,args2);

} else {
mGUIManager->injectChar(arg.text);
}

Allthough this sort of works it does give some strange errors. When you start typing the text is displayed in the TextBox as one would expect. But when I call getText() I only get the first few characters of what was inserted. The amount of characters seems very erratic. And when I use backspace to remove a character the last character gets removed and that line that keeps track where you are in a text shifts a few pixels upward and further backpacing becomes impossible untill you type some new text.

PS: I was using the beta 0.9.7 release above.

Can you reproduce this with the demo app?

Have you tried something like the following?



mGUIManager->setActiveWidget(main_input);

...

mGUIManager->injectKeyDown(static_cast<QuickGUI::KeyCode>(arg.key));
mGUIManager->injectChar( arg.text );


What text were you typing? I just made a long sentence (maybe 50 chars), and everything worked as I expected..

This is how the demo injects input:

bool keyPressed( const OIS::KeyEvent &arg )
{
Ogre::Vector3 camPos;

if( arg.key == OIS::KC_ESCAPE )
mShutdownRequested = true;
else if( arg.key == OIS::KC_UP )
{
camPos = mCamera->getPosition();
mCamera->setPosition(camPos.x,camPos.y,camPos.z - 5);
}
else if( arg.key == OIS::KC_DOWN )
{
camPos = mCamera->getPosition();
mCamera->setPosition(camPos.x,camPos.y,camPos.z + 5);
}

mGUIManager->injectKeyDown(static_cast<QuickGUI::KeyCode>(arg.key));
mGUIManager->injectChar( arg.text );
return true;
}


What's your dev setup?

It seems it was my problem after all. Cegui had a string class that I couldn't pass to a regular string so I did a copy like this

std::string message((char*)input_line->getText().data(), input_line->getText().length());

Which worked for cegui but did strange things with the string I get from the getText() function in Quickgui.

And for a reason totally incomprehensible to me, when I removed this line, the other issue mysteriously dissapeared.

There is still something strange, this time, it's in the demo aswell.

Say, you typed some text, and you put the cursor somehwere in the middle and start using del to remove some characters. The characters get removed, even from the buffer. but the cursor shifts upward like I explained before. When you are at the end and start removing the rest of the characters with the backspace key, you have to click backspace the same amount of times as you pressed delete before any character gets removed. And well some other strange behaviour of the del key in general.

I also get quite a lot of "Quickgui : error in Widget::overTransparentPixel getting correct Mouse to widget position" error when trying to select the TextBox.

PS: I'm using debian etch linux, with gcc version 4.1.2 20061115 as a compiler with Ogre 1.4.5.

Thank you for your help.

Which worked for cegui but did strange things with the string I get from the getText() function in Quickgui.

And for a reason totally incomprehensible to me, when I removed this line, the other issue mysteriously dissapeared.


Nothing strange here. CEGUI::String returns a pointer to a utf8 value, which most of the time can be interpreted as a simple char.
Ogre::UFTString returns a pointer to a uft16 value, which obviously can't be interpreted as a simple char.

With the other issue, I ment the issue with removing characters with backspace. It is quite clear what was wrong with that command to copy a string. But the backspace issue seems entirely unrelated.

Don't know of that is related to it in any way. But I remember seeing the cursor moving upwards when entering a character, that was not available in the used font. Guess kungfoomasta will have to look into it.

Glad some of the issues are resolved. What font are you using? What TextBox are you typing in? I don't see any of the behavior your describe, so I'll need to know what you're doing, and if there are any differences between your use of the demo and mine.

you have to click backspace the same amount of times as you pressed delete before any character gets removed. And well some other strange behaviour of the del key in general.

Give me some text to type in, what textbox to use, and tell me where to position the cursor.

The font used does seem to affect the behaviour. The issues above are with no default font selected.

When you select a fond (tried the acmesa and micross font that were in the tutorial). It shows a square which behaves as a character. When I look at getText().length() the delete key is indead counted as a character.

So it seems that pressing delete does remove the next character as is intended but also inserts a "delete" character into the string, a character not present in any font and causing strange behaviour.

Sorry for the late response on this.. I haven't sat down to test this. I have glanced over some code. Basically when you inject characters into QuickGUI, if it is not found within the list of supported code points, it will not be injected as a character to the active widget. For this reason, pressing the "delete" key should not inject characters into the textbox. Are you modifying the list of supported code points? Also, what environment are you working with?

Well I get the issue in every spot you type text with the provided demo right out of the box.

I've got some more issues aswell:

The checkbox only selects when you click on the border of if it is checked on the lines of the cross, not when you click in that area in between the border.

And when you have a combobox with less than 6 items, so some empty space is still visible on the drop down area and you click on this empty space, then it segfaults on QuickGui::ComboBox::selectItem().

I tested with latest svn, revision 258, on debian linux(etch) and Ogre 1.4.5, and GNU g++ (GCC) 4.1.2 20061115 as a compiler.

If I find some time, I'll enable debug symbols on the QuickGUI build and try to track these down.

The checkbox only selects when you click on the border of if it is checked on the lines of the cross, not when you click in that area in between the border.

I will fix this tonight. The reason for this is because I do transparency picking, and the inside of the check box widget is 100% transparent. If I change the texture to have 1% opacity, it will work.

I will fix that issue and then create a CheckBox widget. I plan on being a little more aggressive with QuickGUI this week.

And when you have a combobox with less than 6 items, so some empty space is still visible on the drop down area and you click on this empty space, then it segfaults on QuickGui::ComboBox::selectItem().

Thanks for reporting this, I will look into it. The extra space is desired behavior, you can manually set the height. (the crash is not desired, however!) I can't have auto sizing of height, otherwise scrollbars will never be used.

Regarding the text input, if you could debug and step through GUIManager::injectChar (I think this is the function name) when pressing the "delete" key, and let me know the flow of execution, that would be helpful.

Sorry you're having these problems with the library.

Ok, i looked into it.

The delete key is read as character 127, which is within the range 9, 32-166 of mSupportedCodePoints. Since 127 is suposed to be the delete key in ascii, the fix is easy enough.


Index: QuickGUI/src/QuickGUIManager.cpp
===================================================================
--- QuickGUI/src/QuickGUIManager.cpp (revision 258)
+++ QuickGUI/src/QuickGUIManager.cpp (working copy)
@@ -41,8 +41,10 @@

// by default, we support codepoints 9, and 32-166.
mSupportedCodePoints.push_back(9);
- for(Ogre::UTFString::code_point i = 32; i < 167; ++i)
+ for(Ogre::UTFString::code_point i = 32; i < 127; ++i)
mSupportedCodePoints.push_back(i);
+ for(Ogre::UTFString::code_point i = 128; i < 167; ++i)
+ mSupportedCodePoints.push_back(i);


mTimer = new Ogre::Timer();


Awesome, glad we found the problem. I forget what structure mSupportedCodePoints is, I should make it into a "std::set", and just removed 127 after adding in the range of code points. Odd that I don't get any output on my screen when pressing Delete, especially if we're using the same font. I was thinking maybe your font had some glyph for code point 127. Either way, I don't want to be injecting *delete* as a character, so I will apply the fix. Thanks for looking into this.

Interesting... the delete key on my laptop yields a Code Point of '0'. So I'm not sure if I should apply your patch. Instead, you should make use of the GUIManager::setSupportsCodePoints(...) functions. My range of code points comes from Ogre, so I assume that its the general code point range.

I have fixed the ComboBox bug, and have changed mSupportedCodePoints to be of type std::set<Ogre::UTFString::code_point>. However, I can't commit this now, because of other tasks I'm also working on. Also, I suck at editting the checkbox images, I couldn't even put a 1% transparent white color inside the box.

I'll update the SVN thread when the changes have been committed. Probably in a few days.