Inputfield not showing the dropdown on end edit

Question

The code that's having the problem:

using UnityEngine;
using TMPro;

public class SpeakerNameInputHandler : MonoBehaviour
{
    public Speaker speaker;
    public TMP_InputField nameInputField;

    public TMP_Text speakerNameTextMeshPro; // Reference to the TextMeshPro object where speaker name will be displayed

    public void SetSpeakerCustomName()
    {
        string newName = nameInputField.text;
        speaker.SetCustomName(newName);

        // Update TextMeshPro text with the new speaker name
        if (speakerNameTextMeshPro != null)
        {
            speakerNameTextMeshPro.text = newName;
        }
    }
}

I wanted to make the dropdown at on end edit to have the command SetSpeakerCustonName but when I tried it with this coding it didn't show and there is only name and string name I was expecting it to change the name of my speakers, the speakers I made is codes based

The codes that is relevant with the code above:

using UnityEngine;
using System.Collections.Generic;

[CreateAssetMenu(fileName = "NewSpeaker", menuName = "Data/New Speaker")]
[System.Serializable]
public class Speaker : ScriptableObject
{
    public string speakerName;
    public Color textColor;

    public List<Sprite> sprites;
    public SpriteController prefab;

    public void SetCustomName(string newName)
    {
        speakerName = newName;
    }
}

Update

Yes there is more than 1 speakers they are listed in the story folder (I am making a visual novel game)

Speakers folder:

Image consisted with the inspector,scene,and hierarchy:

Image of the function in on end edit:

mcmale inspector:

Answer 1

OK, I think I can understand the confusion and I'll try to explain a little bit. But first, since this will be slightly long, I will start with the opposite way of how answers that include historic events are structured and will start with the TLDR first, and do the TSNMI (too short, need more info) after.

TLDR: too long, didn't read

In the case of scripts, you can't reference the actual MonoScript (i.e. the internal representation as an asset of C# source code), but rather instances of it that are used. More on this in the TSNMI.

In the case of MB (MonoBehaviours), you need to drag and drop the Component of a GameObject that uses the script (which in actuality will indirectly reference the GameObject as a persistent reference to that Component.

In the case of SO (ScriptableObjects), since they don't get "attached" to a GO and don't exist as actual objects in the Scene, you'll need to use one of the constructed SOs (meaning one of the ones created with the context menu).

TSNMI: too short, need more info

The reasoning:

Because this means you use an instance, the consequence of this is that it only applies to that object. To put it short, let's assume you have an event that sets the name of a unit in the game, for example a hero in an RPG and that unit is obviously a GameObject (so it has a MB attached to it). Let's say you're creating a party, so you have more than one hero. The game says "please write the name of each hero in your party" (a similar action to what you have in your Visual Novel). You would need to reference a single hero for the InputField event, else you'd end up naming all heroes in your party with the same name, right?

Now, let's assume you have a more static game play, such as a Visual Novel. You have some characters (so a similar situation as in my RPG example) but they're represented as SOs. Well, how do you name one of them and not all of them? If you could use the script, then all of your characters would have the same name. So the way for the game to know you only want to name the second character is to reference the second SO asset.

OK, but how do I handle multiple selections?

Well, you can duplicate the objects that use events (for example the text field), hide all of them and use some logic to show each one at a time. Or you can be lazy and show, for example, all 4 fields for 4 characters, one under the other, then have one single button "Next" or whatever to save it. If you want a cleaner solution, you can change the event target programmatically if you want to only use one text field, for example. In the case of the first solution (multiple text fields) you can do the logic without much code, by using events (meaning on a single event, add multiple targets, one of them having enable = false) if you're not keen on coding.

Exotic cases?

Yes. Keep in mind that SOs is content stored as an asset. Meaning it persists in your whole project, not in one scene. That means it can be referenced everywhere. On the other hand, making your own Unity Event inside a SO will not allow you to reference just about anything. Let's consider an example: how would the game handle an SO used by a MB from Scene 2, when the SO references a MB from Scene 1? Technically it is not possible, since the scene no longer exists and all objects from it are deleted. But can GOs be assets? Yes. Using Prefabs.

But these two cases are an entirely long discussion on their own.

Exceptions to exotic cases?

And yes, there are some ways to handle this, either with multiple scenes, either with UnityEngine.Object.DontDestroyOnLoad() which creates a special persistent scene that will "hold" all your persistent objects. But these cases are an entirely long discussion on their own. These would also start a long discussion.