thanks. I’m going to investigate your advice a a solution.
As for the editor events, check out elgsoft’s plugin linked in this post:
https://forums.unrealengine.com/development-discussion/python-scripting/1604979-editor-utility-widgets-feedback?p=1618600#post1618600
Is it possible using editor widget to change other blueprints default variables within editor and not in game? Also can it make new blueprints in content browser? Like a child of a blueprint, but with different default variables?
I Think this feature is one of the best features ever made inside UE4, really it’s very powerful and could elevate the Engine to a new level.
Thanks for people who’re working on this, You did a great job really.
In 4.23 preview 1, if I attempt to save my EUW while that EUW is open, it will not save because it is “linked to an external package”. If I close the widget and then save the EUW blueprint, then it will save successfully. This happens even with a new, blank EUW, and it happens when the editor tries to autosave. Saves work ok in 4.22.
I went to log a bug, but I can’t select 4.23 as the version so here it is:
Reproduction steps:
Saving will fail with an error message like this:
EditorErrors: Warning: Object ‘WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_C_6’ is in another map
EditorErrors: Warning: Can’t save WidgetX.uasset: Graph is linked to object WidgetX /Temp/Untitled_1.Untitled_1:WidgetX_6 (CreatedUMGWidget) in external map
I’m also getting a crash if I try to save a savegame file from an EUW (I submitted the crash via crash reporter).
I save the state of just about every input to a savegame file when the widget is closed, and restore when it opens… which worked ok on 4.22.
This should be fixed in the next preview. Thanks for calling it out!
Will add this to the list to investigate - thanks!
I made this basic tools using the editor utility widgets, thanks for making these amazing tools :D.
The level management stuff doesn’t work, I couldn’t find any nodes to make duplicating work 
But it’s pretty cool that you can make tools right in the engine now.
Edit : I just have to use Spawn Actor from class to duplicate lol, I am so dumb :rolleyes:
New/different things to try out in 4.23 Preview:
Editor Utility Blueprints (formerly known as blutilities, but renamed to match other editor utility functionality) are now on by default.
Marking a function as “Call in Editor” in Editor Utility Blueprints no longer makes a button in the details panel. Editor Utility Widgets enable you to create much more flexible UIs, so we wanted to unify the locations UI would be expected.
You can base Editor Utility Blueprints on any editor-only class that isn’t a widget. There are some base classes like EditorUtilityActor and EditorUtilityObject to get started with, but editor-only classes in your project will work as well.
The functionality from GlobalEditorUtilityBase and PlacedEditorUtilityBase have been moved to default engine libraries like EditorUtilityLibrary, as well as the EditorScriptingUtilities plugin (so remember to enable that).
Double-clicking now opens the Editor Utility Blueprint for editing, to match other asset behavior.
Editor Utility Widgets now have single property rows and details panels so you can easily expose properties for editing without needing to remake editor UI. A helpful hint is to set “this” node for the Object of these widgets, and then any public properties will show up. (I’ll try to get an example of this mocked up).
You can add a Run function to any Editor Utility Blueprint or Editor Utility Widget which will run on editor start. This will create an instance and allow for binding to stateful editor events.
In EditorPerProjectUserSettings.ini add a section:
[/Script/Blutility.EditorUtilitySubsystem]
+StartupObjects=/Game/ExampleStartupObject
Please report any bugs you find through the bug reporter, and keep showing us your awesome examples!
Thanks!
Does anyone know which .ini contains the settings for which Editor Widget is opened? It’s possible (especially with list views) to create situations where the editor will crash when a widget is created, and since it re-opens any opened Editor Widgets on boot, you don’t really get a chance to close them before the editor just crashes again.
\Engine\Saved\Config\Windows\EditorLayout.ini
saves the entire editor layout, so if you had a tab open that was causing issues, clearing that ini should allow you to boot with the editor’s default layout.
Thanks.
Another question, is it expected that the new DetailsView widget shows all properties even if they are Private (the behavior is the same for native or BP properties)? They cannot be modified in the DetailsView if they are not Public/Instance Editable which makes sense, but the fact they are displayed is pretty weird since they look editable but just don’t respond to interaction.
Is the intended use of that widget to expose one or a few specially-crafted categories of properties and it’s up to us to make sure we don’t have private properties in there?
Hm - there actually is an advanced flag on the details view to Force Hidden Property Visibility. If that’s not on and you’re still seeing this behavior, could you report it through the bug tracker? Thanks!
There’s no real bug, the ForceHiddenPropertyVisibility flag is doing what it’s supposed to, it’s just that if you want to only show properties that are marked as InstanceEditable (in BP) or EditAnywhere (native), you can’t.
Based on some quick testing in editor:
Every Property created in Blueprint has CPF_Edit regardless of their other flags.
When a BP property is marked as InstanceEditable, it loses the CPF_DisableEditOnInstance flag (which seems to be a flag specific to Blueprint properties)
Personally I think it would be nice to change the ForceHiddenPropertyVisibility flag into an enum where you have:
Show everything
Current ForceHiddenPropertyVisibility=true
Show properties with CPF_Edit
Current ForceHiddenPropertyVisibility=false
Show only instance editable properties
BP: CPF_Edit && !CPF_DisableEditOnInstance
Native: Whatever CPF_Edit + EditAnywhere is. Not sure what combination of flags represents an EditAnywhere native property.
I just don’t see the DetailView in its current form being that useful unless you use it only on classes where everything is fully exposed (BP InstanceEditable or native EditAnywhere), because you can’t actually change those non-exposed properties if you click on them in the DetailView widget from my experience.
For example, with these 3 Blueprint properties in a UMG DetailView with ForceHiddenPropertyVisibility=false, I see all 3 properties but only the first one can be changed. The other 2 just don’t respond and I have no way of hiding them without moving them into a different category and starting to whitelist the categories instead of showing all properties.
Thanks for the detailed breakdown! We’ll look into this on our end. 
Hi! Thanks for the amazing system! I come here with a problem though I can’t spawn a tab from C++.
I put a plugin on the Marketplace and a customer let me know that it’s hard to find it in the Content Browser. It turns out that it’s a part of Engine Content when installed from Marketplace. So what I’m trying to do is to add a menu button to the level editor (Window -> My tool) that will spawn the Utility Widget.
The linker complains:
Is it on purpose that EditorUtilityWidgetBlueprint.h is not a part of BLUTILITY_API? If yes, then at least an exposed function for that purpose would be very useful.
I based my function on AssetTypeActions_EditorUtilityWidgetBlueprint.cpp. I also followed the invaluable tutorial by IsaraTech, but they just skipped the spawning part (probably due to the same problem) 
Below is the part of my code that causes trouble:
if (!LevelEditorTabManager->CanSpawnTab(RegistrationName))
{
IBlutilityModule* BlutilityModule = FModuleManager::GetModulePtr<IBlutilityModule>("Blutility");
UEditorUtilityWidgetBlueprint* WidgetBlueprint = Cast<UEditorUtilityWidgetBlueprint>(Blueprint);
WidgetBlueprint->SetRegistrationName(RegistrationName);
LevelEditorTabManager->RegisterTabSpawner(
RegistrationName,
FOnSpawnTab::CreateUObject(WidgetBlueprint, &UEditorUtilityWidgetBlueprint::SpawnEditorUITab)
).SetDisplayName(DisplayName).SetGroup(BlutilityModule->GetMenuGroup().ToSharedRef());
BlutilityModule->AddLoadedScriptUI(WidgetBlueprint);
}
In 4.23 Preview, the Editor Utility Subsystem has a function SpawnAndRegisterTab that should be able to help with that, and it just takes the Editor Utility Widget Blueprint as an input.
Amazing! Thanks
I was wondering if it’s possible in any way with the current Editor Utility mechanics to compile the lights for a level (and get notified when it’s done), would be really great for automatizing the process of rebuilding multiple levels when some global setting, actor, material or sublevel changes.
That’s great!!
I have a question though, im working on a project that is still in 4.22, is there anyway getting a reference of the Editor Utility Widget within a regular widgetblueprint? right now, I get warning that it can not access the variable called EditorWidget (a variable ref to my editor utility widget)