Edit box question

In my game, I have a Player editor with about 12 - 20 edit box fields, depending on the player class. It also has Previous and Next buttons. I’ve discovered that if I hit Next 144 times, I start getting corrupted images.

My current logic is to remove all fields when they hit Next and then re-create the fields and add them. I may have to try reusing them instead (which is probably smarter).

Here’s how I remove them. Can you tell if I’m missing something?

  for (int i=0; i<kPlayerCardInvalid; i++)
    if (editBoxList[i] != nullptr)
      // editBoxList[i] = nullptr;
    // removeEditBox(&editBoxList[i]);

  for (int i=0; i<kPlayerCardInvalid; i++)
    if (editBoxList[i] != nullptr)
      editBoxList[i] = nullptr;

Is it possible for you to post a screenshot of what the images look like before and after corruption, or even a small project that reproduces the issue? It’s a little concerning that something like this would happen.

Yeah, I’ll post a screenshot soon, once I get on my wife’s laptop. Interestingly, I’m now sitting at my main computer, and I get different behavior when this bug hits. On this computer, the UI simply stops updating. I can see my console messages in Visual Basic still logging, but the UI is now completely lost, and I have to kill the app.

I’m also going to try to redesign it to reuse boxes, but so far, that’s not working right. It seems when I remove a box from the display, it gets lost or something.

thanks much!

BTW, I’m using 3.17.1, if that helps, and I just realized that I didn’t share my code that actually creates the edit boxes. Maybe I’m doing something wrong there?

ui::EditBox *PsfEditBoxDelegate::createEditBox(float width, float ht, int maxLen, int tag, ui::EditBox::InputMode inputMode)
  Size sz = Size(width, ht);

  ui::EditBox *box = ui::EditBox::create(sz, cocos2d::ui::Scale9Sprite::createWithSpriteFrameName(SLICE_BUTTON_IMAGE));
  // box->setReturnType(ui::EditBox::KeyboardReturnType::DONE);  // try DONE, SEND, SEARCH, GO

  box->setFont("fonts/arial.ttf", ADJUST_X(10));
  // box->setFontSize(18);
  // box->setFont("fonts/arial.ttf", ADJUST_X(18));
  box->setFont("fonts/arial.ttf", ADJUST_X(12));
  // box->setFontSize(17);

  if (isIphoneX())
    box->setFont("fonts/arial.ttf", ADJUST_X(11));

  // box->setAnchorPoint(Vec2(0.0, 0.5));
  box->setAnchorPoint(Vec2(0.5, 0.5));
  // box->setInputFlag(ui::EditBox::InputFlag::INITIAL_CAPS_WORD);

  return box;


I updated my code to 3.17.2, and it still happens. Worse, I found it’s not really isolated to this code. If I go to multiple screens, each having lots of edit boxes, it will eventually hit this problem. It seems as if something with the edit boxes isn’t being freed. :frowning:

Do the profiling tools on show you any memory leaks or areas of performance issues? “Instruments” in Xcode is a bit better than Visual Studio for this, so if you get a chance, try that out. More specifically, use the “Allocations” and “Leaks” profiles to see if anything strange is happening.

The edit box creation code you posted doesn’t seem to have any issues.

Unfortunately, my game stopped building in xcode last Fall. I believe the xcode update around September caused it, and I haven’t been able to get back to it. The majority of my sales are in Windows, so I’m trying to finish up this version for Windows and then I’ll go back and try to get it building in xcode again. I’ve looked through the UIEdit and UIEditImpl code, looking for anything.

I did confirm that it’s actually more of an issue of “how many edit boxes have I opened anywhere in my application” rather than in a single screen. I tested moving around between screens that create edit boxes, and it happens consistently.

Are there alternatives to EditBox that work in Windows?

Thanks so much for your time. Have a good night.

You can use a tool like Deleaker to track down issues if the built in profiling tools aren’t good enough.

Thanks! I’ll try that. Meanwhile, given my time crunch, I’m redesigning this particular screen to reuse fields as much as possible. This won’t solve the problem, but will make it take much longer to crash. I’ll come back to this after I complete more essential features. Thanks again for your help and time.