Is this a Common UI bug? Or did I make some kind of mistake?

When I change Common UI Button “Class Defaults” attribute “Style”, it not works unless I reboot unreal engine. It always Restore to the settings at engine startup(It shows class changed in Details Pannel, but print class name is wrong).


Here is My step:

  1. Create a blueprint extends CommonActivatableWidget, named “WBP_CommonActivatableWidget”
  2. Create two blueprint extends CommonButtonStyle, named “ButtonStyle1” and “ButtonStyle2”
  3. Create a blueprint extends CommonButtonBase, named “Button_Simple”
  4. Add custom button to “WBP_CommonActivatableWidget”
  5. go back to set “Button_Simple” blueprint Class Defaults attribute “Style” = “ButtonStyle1”
  6. In “Button_Simple” blueprint Call “Get Style” Node to print

First time, it print “ButtonStyle1” class, but when I change Class Defaults attribute “Style”= “ButtonStyle2” , it still print “ButtonStyle1” class, unless I keep “Style” = “ButtonStyle2” and reboot unreal engine.

Is this a Common UI bug? Or did I make some kind of mistake?

What you’re encountering seems to be related to how Unreal Engine handles property changes in blueprints, particularly with Common UI and the Style attribute. This behavior might not necessarily be a bug, but rather how Unreal caches or initializes properties in certain cases. Here’s a breakdown of what might be happening and how to address it:


Likely Causes:

  1. Caching Issue:

    • Unreal Engine may cache certain properties, like the Style attribute, at blueprint compilation or engine startup. Changing the Style in the Class Defaults may not trigger a proper update until the engine is restarted.
  2. Property Initialization:

    • Some properties, especially those tied to class defaults, might not reinitialize dynamically at runtime when changed. This could explain why the Get Style node still references the original ButtonStyle1 until the engine is rebooted.
  3. Blueprint Editor Not Refreshing:

    • The Blueprint Editor occasionally does not fully propagate changes to the runtime instance. This is common when changing class defaults rather than runtime variables.
  4. Common UI Framework Quirk:

    • The Common UI framework has certain quirks when working with Style attributes and class defaults. The behavior you’re seeing could stem from how Common UI widgets are constructed and initialized.

Possible Solutions:

  1. Force Blueprint Refresh:

    • After changing the Style attribute, try recompiling your blueprint by clicking Compile in the toolbar. Then save the blueprint. Sometimes this forces Unreal to recognize changes without restarting the engine.
  2. Use Runtime Initialization:

    • Instead of relying solely on the Class Defaults for setting the Style, try setting it dynamically during the Begin Play or Pre Construct events in your Button_Simple blueprint. For example:
      On Begin Play:
      Set Style -> "ButtonStyle2"
      
      This ensures the style is explicitly set at runtime, avoiding potential caching issues.
  3. Debugging the Style Property:

    • Add debug output to verify whether the Style is correctly set when you change it. For example, log or print the Get Style output after the blueprint is recompiled to confirm the property change.
  4. Force Widget Rebuild:

    • If the widget or button isn’t refreshing after the Style change, you can try calling a function like Invalidate Layout and Volatility on the widget to force it to rebuild.
  5. Test in a Clean Project:

    • Create a minimal test project to verify if the issue persists with the same steps. This will help you determine if the problem is specific to your project setup or a Common UI issue.
  6. Check for Common UI Updates:

    • If you’re using an older version of Unreal, ensure you’re on the latest version. Common UI has been updated several times, and newer versions might address this behavior.

Workaround:

If the issue persists despite these steps, you can implement a temporary workaround:

  • Always apply the Style dynamically during the widget’s initialization (e.g., Pre Construct or Begin Play).
  • Use variables to store your desired Style and apply it programmatically, bypassing the reliance on Class Defaults.

Is it a bug?

It could be a minor bug or a limitation in how the Common UI framework initializes its properties. If none of the solutions above resolve the issue, consider reporting it to Epic Games via their Unreal Engine Bug Submission Form with the detailed steps you’ve provided.

Let me know if you need help implementing any of these solutions!