MultiLineEditbox - Nonprinting keypress adding spaces

[SongOfTheWeave]

I defined a new MultiLineEditbox widget that was simply a copy/paste from the TaharezLook MultiLineEditbox with different images.

The scheme entry is the same as the TaharezLook/MultiLineEditbox except for the name and the looknfeel lines.

The widget displays properly, but nonprinting keystrokes (such as arrowkeys, ctrl, shift, delete, etc.) insert a space as well as performing their normal function, for example, the arrow keys move the cursor in the specified direction and insert a space.

The TaharezLook/MultiLineEditbox still functions properly. All I did was change the images.

Any insight into why this is happening?

[CrazyEddie]

...nonprinting keystrokes (such as arrowkeys, ctrl, shift, delete, etc.) insert a space as well as performing their normal function...

Normally that only happens when you do a character injection (as well as key up /key down) for those type of keys.

Not sure why the standard Taharez multi line editbox would not be affected also, though.

[SongOfTheWeave]

For every keypress I am injecting KeyDown and a char. Which seemed to work fine before, so I assumed nonprinting keys had a null char that was ignored as their evt.text. I suppose that's an OIS specific issue though.

So, the way I should be using injectChar is to only call it when I have a printing key stroke? Something like:

pseudocode:

Code: Select all

keyPressCallbackMethod(args)
{
   bool bInject = false;
   switch (scancode)
   {
      case ALL_PRINTING_KEYS:
         bInject = true;
         break;
   }

   guiSystem->injectKeyDown(scancode);
   if (bInject)
      guiSystem->injectChar(ch);
}

[SongOfTheWeave]

So I re-tested this and even if I change the offending MulitLineEditbox back to a Taharez MultiLineEditbox, rather than my custom one, it still exhibits the issue, but other MultiLineEditbox' (using the Taharez looknfeel) elsewhere in my program do not.

The whole program uses the same onKeyPress method to inject inputs to CEGUI where it always injects a key and a char.

Time to go back and figure out what I changed at the same time as I defined the custom MultiLineEditbox I guess.


Edit: Is it possible that this is a font thing? The deviant editbox uses a different font... <.<

Edit2: As bizarre as it sounds, switching the offending editbox back to the same font as everything else (tahoma-8) fixes the issue. I had been using Consolas. Are weird chars being inserted that tahoma just doesn't have a glyph for but Consolas uses a ' '?

Edit3: No that's not it, if I ofstream the editbox (tahoma) text to a file there are no weird spaces, but if I output the editbox (consolas) text to a file after arrow keying around and shooting the thing full of spaces, the file has all characters prior to the first inserted space then nothing after it.

[Rackle]

Are you also injecting key up?

[SongOfTheWeave]

Are you also injecting key up?

Yes, later (when the key is released.)


Edit: Allow me to sum up -

The MultiLineEditbox is behaving differently (screen behaviour and true content (text) behaviour as witnessed by streaming out the text content to a file) depending on the font that I use.

Tahoma behaves somewhat properly except that no spaces or '\t' at the beginning of a line are displayed (when filling the edit box from a text file.) Using Tahoma I get proper text when I stream it to a file (using editbox.getText()).

Consolas inserts spaces on screen whenever I press a non-printing key (except for a few like backspace seems to work properly.) But when I output the getText() to a file all text is gone after the first inserted space.

[CrazyEddie]

The reason for the different behaviour with different fonts is that the other font is obviously poorly made and contains (empty) glyphs for those non-printable character codes. When you inject a char code that reaches an editbox, CEGUI asks the font assigned to it "can you print this character?" if it gets a positive response, the code is added to the editbox string.

While much of that may seem a bit 'iffy' it's done by design. It allows for non-standard usage of those codes (say if you have a custom font with some icons in those glyhs) - this ability enables rendering of those custom / specialised cases.

You may be thinking "why not just reject all non-printable chars?" well, as mentioned above, we do. The font is saying it can print them, so they're accepted.

So, let me restate what I intended in my first reply more directly so there is no confusion.

The easiest, best, "CEGUI project" endorsed solution to this is to make sure that you do not inject character codes for non-printable keys - unless you are doing something non-standard.

[SongOfTheWeave]

Lovely.

Thank you for the explanation and the clarification.