Skip to content

Game.UI.Widgets.IFieldBuilderFactory

Assembly:
Game (assembly name not specified in provided source)

Namespace:
Game.UI.Widgets

Type:
interface

Base:
(none — this is an interface)

Summary:
Factory interface used by the UI widget system to create FieldBuilder instances for a given member type and set of attributes. Implementations examine the supplied member type and attributes and either return a suitable FieldBuilder configured for that member, or null when the factory cannot handle the requested type. Nullability annotations from Colossal.Annotations indicate that the returned FieldBuilder may be null and that the parameters are expected to be non-null by the caller.

Fields

  • This interface declares no fields.
    Implementations may maintain fields/state as needed, but the interface itself exposes only the TryCreate factory method.

Properties

  • This interface declares no properties.

Constructors

  • Interfaces do not declare constructors.
    Implementations provide their own constructors as required.

Methods

  • [CanBeNull] FieldBuilder TryCreate([NotNull] Type memberType, [NotNull] object[] attributes)
    Creates (or attempts to create) a FieldBuilder appropriate for the specified member type and attributes.

Details: - memberType: The Type of the member for which a FieldBuilder is requested (e.g., a property or field type). The parameter is annotated [NotNull]; implementations can assume the caller supplies a non-null Type. - attributes: An array of attributes (typically the custom attributes retrieved from a MemberInfo) that may influence how the FieldBuilder is created/configured. This parameter is annotated [NotNull]. - return value: Returns an instance of FieldBuilder when the factory can provide one for the given type/attributes, or null ([CanBeNull]) when it cannot. Callers should handle a null return to allow other factories or fallback logic to run. - Behavior recommendations: Implementations should not throw for unsupported types — return null instead. Implementations may inspect attribute instances (by type) to adapt the created FieldBuilder (e.g., range, formatting, custom editors). - Threading: Typically used by UI code on the main thread. If an implementation allocates or caches resources, consider thread-safety if the factory may be accessed from multiple threads in your mod.

Usage Example

using System;
using Colossal.Annotations;
using Game.UI.Widgets;

public class SimpleFieldBuilderFactory : IFieldBuilderFactory
{
    [CanBeNull]
    public FieldBuilder TryCreate([NotNull] Type memberType, [NotNull] object[] attributes)
    {
        if (memberType == null) throw new ArgumentNullException(nameof(memberType));
        if (attributes == null) throw new ArgumentNullException(nameof(attributes));

        // Example: create a numeric FieldBuilder for integer types
        if (memberType == typeof(int) || memberType == typeof(long) || memberType == typeof(short))
        {
            var fb = new FieldBuilder();
            // configure fb based on attributes (e.g., range attribute)
            foreach (var a in attributes)
            {
                if (a is RangeAttribute range)
                {
                    fb.Min = range.Min;
                    fb.Max = range.Max;
                }
            }
            return fb;
        }

        // Return null when this factory cannot handle the requested type.
        return null;
    }
}

Notes and tips: - The attributes array will typically come from reflection (MemberInfo.GetCustomAttributes(true)). Match attribute types rather than relying on ordering. - Compose multiple factories if needed: a registry can iterate factories and use the first non-null FieldBuilder returned. - Keep factories lightweight; heavy initialization can be deferred or cached inside the concrete factory implementation.