[UMG] OnTextCommitted failing without debug

I was attempting to make a simple UMG HUD to display a plugin I have written, when I came across this unexpected behaviour.

I have a few Text Boxes, and Text Inputs, on the inputs I use OnTextCommitted, and it usually works, except in this one instance where I am completely lost.

First, this one text input wouldn’t fire the OnTextCommitted event unless I turned on the Editor Debug, after words it would work fine and update as expected.

Second, if I added a print function (I assume any function would work) before the Switch statement it started working fine as well. But not without it.

I have cleared and changed the text box, re-setup the events, resetup the graph, it still does this, just for this text box…

The Image below works, and the event is fired and all updates happen as expected.

This image below doesn’t work… I have set this up half a dozen times already… it only happens on this box

This is such an obscure thing, I am not even sure I could reproduce it again, because I have no idea why this one button on this widget will not fire the event without another function in the way.

Hello ,

I was unable to reproduce this issue on our end. I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Are you using any third party plugins?
  2. If so, does this issue still happen if they are removed?
  3. I notice that you said you might not be able to reproduce this issue in a clean project, however could you try and reproduce this issue in a clean project?
  4. If the issue reproduces, could you provide a detailed list of steps to reproduce this issue on our end?
  5. Could you provide screen shots of any other blueprints/widgets that may be involved?
  6. Could you try verifying your engine (via the drop down option on the launcher)?

I have done a few more tests… and I believe it has something to do with my plugin… not sure how this is happening, but it seems that the delay that print gives is give my code “enough time” to execute, which doesn’t seem right, as it should all be linear… unless something is getting optimized out because there is no direct interation with UI, it is just passing data indirectly.

With out debug, or a print, it appears that the execution path isn’t even happening.

This is does indeed seem to be the case… my code in c++ is optimized out (partially)… if I add a UE_LOG it will run the function every time… without it break points aren’t even hit about 75% of the time… I think this issue is resolved, but if any one can give a hint I would be greatful.

Sorry for all the thoughts here… I have narrowed it down even more, Now we might have part of the issue. I will make a quick video of this, as it will hard to explain, but I will give it a go.

The class runs fine if I don’t have the editor open, if I leave the editor open and don’t call a print (or any other function that interacts with UE) it will not run the ApplyGameRule function, if I add a UE_LOG in the function, it will run it. So final point is, if I have the BP editor open, it will skip the function… Like I said I can’t really explain this, but let me make a video and you will understand.

link text

Video file of this issue

I am happy to hear that you have narrowed things down. Would it be possible for you to provide the project so that I could have a closer look?

I will tonight, if you can give me a secure location to upload too.

Hello ,

If you would like to provide the project privately you could do so by sending it to me as a private message on the forums. This can be done via a link to drop box or google drive.

File sent via PM on forums…

Just as a reminder, line 19 and 20 in ValueGameRule.cpp is where the band-aid is.

Hello ,

I could not reproduce this issue on our end with the project provided. However, could you try removing any 3rd party plugins and let me know if this issue still occurs?

After working on this issue more, a few re-compiles, I can no longer reproduce this issue… honestly not sure what has changed that was related to this, but I am going to close this for now, unless I can reproduce this myself again.