[Journal - Custom Auto-Completion Code Revisited]

Custom Auto-Completion Code Revisited

Sunday, June 12, 2005

Here's a new version the GetInterfaceImplementation function, which I presented here as an example for custom code usable in WebEdit.NET's token expansion feature. That function would be build as part of a Script AddIn.

The new version is handled by .NET Console, WebEdit's code interpreter. It's a bit better in that there's a list of interfaces to choose from, but see for yourself how it differs from real C#: 

ImplementInterface(sLanguageName)
{
    lang = App.Context.LanguagePool.GetLanguageByName(sLanguageName);
    Check.Reference(lang, string.Concat("Language '", sLanguageName, "'not found."));

    assistant = lang.CodeAssistant;
    Check.Reference(assistant, string.Concat("No code assistant available for language '", sLanguageName, "'."));

    faces = new System.Collections.Specialized.StringCollection();
    foreach(a in AppDomain.CurrentDomain.GetAssemblies())
    {
        foreach(tp in a.GetTypes())
        {
            if(tp.IsInterface){
                faces.Add(tp.FullName);
            }
        }
    }

    frm = new Gregor.UICore.Dialogs.FCombo("Implement Interface", "Enter interface type name:", faces, null, false, WebEditApp.ImageList, "Interface.ico");
    frm.ShowDialog(WebEditApp.MainForm);
    sType = frm.UserText;
    if(Flow.IsString(sType))
    {
        tp = Reflect.FindType(sType, true);
        Check.Reference(tp, string.Concat("Type '", sType, "' not found."));
        Check.Expression(tp.IsInterface, string.Concat("Type '", sType, "' is not an interface."));

        info = new Gregor.Editing.EditAssistance.CCodeAssistanceInfo(Reflect.GetTypeInfo(tp), WebEditApp.EditManager.IndentString);
        if(assistant.ImplementInterface(info))
        {
            info.Result; // last statement == return value
        }
        else
        {
            string.Empty; // last statement == return value
        }
    }
    else
    {
        string.Empty; // last statement == return value
    }
}

You can feed that function to the code interpreter by pasting it into a document window, and issuing the following command: 

code:Vars.Eval(Vars.TextAll)

Hooking up that function to an auto-text token is no different: use a parameterized token like the following (possibly wrapped by an alias): 

$ImplementInterface("C#")%

Nesting Parameters?

One issue with parameterized tokens in auto-text is nesting parameters. Imagine you could have a call like this: 

$ImplementInterface($Language%)%

Note that I can't allow just to name the function in the token list without dollar/percent signs, since it needs to be distinguished from literal tokens. Nevertheless, nested parameters are doable of course, but I'm somewhat hesitant about supporting it, because you never know what happens with existing user data. Now, nesting parameters for user function arguments only makes sense when querying the user for values (code expression can be evaluated directly in the user function). Meanwhile, there are a couple of enhancement in my framework for dealing with user input: