jbruening / ugui-mvvm Goto Github PK

Could not get event m_OnValueChange on UnityEngine.UI.InputField
UnityEngine.Debug:LogErrorFormat(String, Object[])
INPCBindingEditor:GetEvent(Component, SerializedProperty) (at Assets/Packages/MVVM/ugui-mvvm/Editor/INPCBindingEditor.cs:82)
INPCBindingEditor:FigureViewBinding(INPCBinding) (at Assets/Packages/MVVM/ugui-mvvm/Editor/INPCBindingEditor.cs:46)
INPCBindingEditor:FigureViewBindings() (at Assets/Packages/MVVM/ugui-mvvm/Editor/INPCBindingEditor.cs:28)
INPCBindingEditor:OnPostProcessScene() (at Assets/Packages/MVVM/ugui-mvvm/Editor/INPCBindingEditor.cs:18)

hi jbruening,
I looked at your code,there are many reflection .
Is using reflection int Unity3d decrease the performance?
thx :)

I'm experiencing an issue with the PropertyBinding. It works mostly perfect but when I want to do a TwoWay binding, the target needs to have two UnityEvents. If there is only one, the dropdown won't appear and the single UnityEvent that does exist in the Target class won't get automatically assigned.

Steps to reproduce:

1. Create new class with one property and one UnityEvent (that is invoked when the property changes)
2. Create source class that implements INotifyPropertyChanged and has a property
3. Add a PropertyBinding component to some GameObject
4. Add the first class as the target and assign its property
5. Select Mode = TwoWay
6. Add the other INotifyPropertyChanged class as the source and select its property
7. Run play mode and change the two properties

Behavior:
Source updates target property but not vice versa

If I create two UnityEvents in the target class and select one of them in the dropdown (making sure it's invoked when the property changes ofc), everything works. So it seems that the PropertyBindingEditor class needs to have something selected in the dropdown for two way data binding to work. It won't select the single UnityEvent automatically behind the scenes. I assume that was the idea, to hide the dropdown and select event automatically if there is only one event but unfortunately it doesn't work.

I simply love this data binding implementation, so I really hope there is a way to fix this. I think the problem is in the PropertyBindingEditor somewhere, but my knowledge of EditorGUI scripting and reflection isn't enough to fix it myself.

in lua mvvm，i can do this,second parameter is a table,third para is a decorator,make a suit style let view show
self:bind("num", {"inventory.current_used", "inventory.capacity"},function(current_used, capacity)
    return ("%d/%d"):format(current_used, capacity)
end) --  "5/100"

in c#,I didn't expect any good solution. do you have any good idea? pls tell me ! thanks

INPCBinding compilation fails when targeting UWP because IsValueType and BaseType are not supported. There is a way to overcome this using type.GetTypeInfo().BaseType instead of type.BaseType and the same for IsValueType. Should I submit a PR with a fix?

Having every available class be present in the DataContext dropdown is a little much in a large project. There is a reasonable delay for every letter typed as the list updates.

Even though it adds overhead to the consumer, I'd recommend we introduce an Attribute and/or common base class for classes that should be ViewModels so that the list can be filtered down.

When leaning in to the mvvm pattern this is designed to support, it is very common to design a piece of UI in Editor without a concrete piece of data to bind it against until runtime.

In this scenario it would be great for the binding to provide a mock value based on the data type (possibly random, possibly based on the property name, possibly customizable through an attribute on the property).

Ideally this value would also be modifiable in Editor for easy testing of longer/shorter strings/etc. (Maybe stored as an independent serialized value in a super ugui-mvvm-editor dictionary of binding properties > mock values?)

Repro Steps

1. Use an ItemsControl script to spawn a collection of prefabs (make sure the itemtemplate prefab has a commandbinding on it eg - a grid layout of clickable buttons)
2. Try using it in the UnityEditor - it works fine and the spawned buttons from itemscontrol are clickable and execute the CommandBinding as expected
3. Try deploying the same to a UWP - the spawned prefabs lose their CommandBinding.

Root Cause
On deeper investigation, it turns out that the gameobject that gets created for the item template prefab is missing the "ExecuteCommand" handler for its click event. This happens because when item template instantuiates gameobjects in editor, it also runs the corresponding "FigureViewBinding" method. However since that method exists in the Editor script, the event handler is never added to the game objects that get created in the UWP.

This is also the case for nested prefabs.

Adding this one on behalf of @ryantrem who may be able to provide more details.

"It would also be good to figure out a way to have better cleanup of values produced by bindings. For example, a converter could convert a byte array to a unique Unity Texture2D (e.g. a profile picture). Since there is only one consumer of the Texture2D in this case, then it should be cleaned up whenever a new value is produced by the binding, or when the target GameObject is destroyed. On the other hand, a converter could convert an enum to one of a standard set of shared Unity Texture2Ds (e.g. a status indicator). In this case, then Texture2D provided by the binding is shared, and should not be cleaned up. Maybe there is just an extra property on the binding to determine whether resources should be cleaned up, or maybe there is some extra property on the converter, or maybe there is some extra data somehow associated with the value produced by the converter... not sure."

The scenario that hit this was attempting to create a prefab for a custom button type. At the root of the prefab is a DataContext expecting a type of ICommand, to be provided by the consumer of the prefab.

Lower in the prefab is a CommandBinding that attempts to bind the DataContext to an OnClick event. This is successfully done by asking for the property 'this' (i.e. it does bind at runtime as expected), but the Editor UI complains that the property is invalid.

A simple fix for this may be including the keyword 'this' in the property list.

When working in a repo with a long (often well-nested) namespace, filling in fields such as 'Type name' on a Data Context can be a cumbersome experience, as every result starts with the same namespacing (e.g. Org.Studio.ProductName.ClassName), so every suggestion gets cut-off before it can be distinguished from the other suggestions.

One solution to this may be smart ellipsing of suggestions, using '.' as the delimiter, collapsing away all suggestions that share the same namespace groups.
Before:
Org.Studio.ProductName.Area.ClassName
Org.Studio.ProductName.Area.OtherClassName
Org.Studio.ProcuctName.Area2.ClassName
After:
...Area.ClassName
...Area.OtherClassName
...Area2.ClassName

An additional solution may be making the suggestion box horizontally scrollable.

Designers on our team have expressed confusion with the name INPCBinding. Developers know what INotifyPropertyChanged is, but this doesn't mean anything to designers, and they have asked us why it isn't just named PropertyBinding (which they would understand, and would have a naming scheme more similar to CommandBinding). I think it would be great to change the name, especially if there is a way to do so without breaking existing assets (not sure how to do this when the class name changes).

@ritijain @MRW-Eric

Repro Steps

1. Create a hierarchy where an INPCBinding exists on a disabled gameObject
2. Assign a DataContext
3. Re-enable the gameObject hierarchy which contains the INPCBinding

Actual
INPCBinding will not bind to the ViewModel properly

Expected
INPCBinding should still bind to the view model

Investigation
INPCBindings register with the DataContext on Start(), and the bindings to the ViewModel are only done when the DataContext is set. This means that disabled INPCBindings will not be registered with the DataContext when ViewModels are set, and so will not be subscribed to the INPC event.

One workaround right now is to have a helper that rebinds the DataContext when one of these object hierarchies is enabled for the first time. However, it would be expected that new bindings that are registered while a DataContext is available should be bound immediately.

The dropdown appears to be showing compiler generated classes as well, which may be confusing for the user, and also bloats up the suggestions box. These should be marked with CompilerGeneratedAttribute, so they can be filtered out from the results

When working with a Command Binding in the Editor it is easy to jump to the target button (or other control), as well as the source data context (or other high level parent).

The common case that is not covered is jumping to the code that is implementing the command. This should probably be associated with the Source > Property field, most likely as an additional button to jump there. It could be a done as a double-click (like object reference fields) if that doesn't feel unexpected and disruptive to the normal interactions of a text field (maybe only at runtime?).