How to get the name of the control type, for example:Dialog.Control("name").type?

Help & Support
, ,
1 
// Example: Assuming it is used to reset all data
// Below is the pseudocode

// Dialog.Control("namme").type
var xctrl = Dialog.Control("name");

// Because the property is not supported, this is an error.
var xtype = xctrl.type; 

if(xtype === "combo"){
    xctrl.value = 0;
}else if(xtype === "listview"){
    xctrl.RemoveItem(-1);
    xctrl.RemoveGroup(-1);
}else if(xtype === "edit"){
    xctrl.value = "";
}else{
    // DOpus.Output("type error");
}

In addition to the above control types, there are also: tab, group, checkbox, combo, radio, listview, edit, static, markuptext, etc.

Obtaining the type name of the object through Control.type makes the program simple and will not exit the program due to exceptions, but it is not supported at the moment.

2

Controls do not appear magically : you're the one creating them programmatically or at design stage, so for a control name you should already know what type they are (either from the designer or from your code).

So, if you really need this name to type association, you can create a map variable (local that you pass to functions, or global so every function in your code can access it) which associate your control names to their named types. You'll have to populate it at startup (for designer controls) or when you add programmatically your controls.

One point to be careful about if you intend to use the tab control or if your function/command/app is managing multiple windows : control names have to be unique by window, but not script-wide (you can have a combo control named control1 in one window, and a checkbox control with the same name in another window). In such case, you might need another map to associate the dialogs to the previous map (and one "control name" <=> "control type" map for each dialog).

3

Thank you for PassThePeas' answer. Based on your provided ideas,

// Implementation code
var controlMap = {
    "checkbox1" : "0",
    "checkbox2" : "0",
    "listview1" : "1",
    "edit1" : "2",
    "combo1" : "3",
    // ....
};

// Test
this.XResetData("listview1");

// Reset form data
function XResetData(controlName){
    var xctrl = DOpus.Dlg.Control(controlName);
 
    // Because the property is not supported, this is an error.
    // var xtype = xctrl.type; 

    var xtype = controlMap[controlName];
    if(xtype === "3"){
        xctrl.value = 0;
    }else if(xtype === "1"){
        xctrl.RemoveItem(-1);
        xctrl.RemoveGroup(-1);
    }else if(xtype === "2"){
        xctrl.value = "";
    }else{
        // DOpus.Output("other type...");
    }
}

Some questions:
1.If the program has a lot of controls, it is very difficult to maintain.
2.It cannot be encapsulated into a global function (interface), which can be used by all scripts, not just the current program.

My idea is that the official support for Dopus.Dlg.Control("xxx").type property would be helpful.

4

I'm sorry, but I think I'm missing something here :frowning:

First : instead of numbers to identify your types, you could go with explicit type names, it would be more readable.
Then, resetting data in a dialog, IMHO, is very specific to each dialog.
If we take a checkbox : sometimes you'll want it checked by default, sometimes unchecked.
If we take a combo box : sometimes, you'll want it empty, sometimes you'll want to have it populated with relevant values according to what your script does. And if there are multiple combos, each one will have to be populated with different things (and clearing it empty before populating is one easy step in that process).
edits : sometimes empty, sometimes with a default value.
I'll stop here, I think you get the point.

Whenever I have some dialog in a script, I do have some kind of InitDialog (or ResetDialog) that makes it in the proper state according to what has to be done, and I find it much easier to do based on the control names which are speaking to me when I do it, rather than based on the control type (I've made quite a few dialogs now, and never had to rely on the control type : acting with knowledge on every control by using its name is really all is needed).
That Init or Reset function might even take a parameter so that the global state can be altered afterwards upon some user interaction (and then either clear or populate differently some controls).

Anyway, if you really want something "generic", one thing you could do, but I do not advise it, is to make a function that goes and read the .js file to parse the xml dialogs description at the end, and that makes :

  • A map DialogControls : for each dialog name it associates another map
  • For each dialog control, that map will associate "control name" and "control type" which are both attributes of the xml.
    Then you could call your generic Reset function with the first map as a parameter.

Yet, honestly, I think in practical use afterwards, you'll execute your reset function only to then go and initialize properly with meaningful values your different controls, leading to extra code, not helping the readability of the code, and getting extra unneeded execution steps.

Last idea : use proper and consistent naming of your controls : every combo box has a name like "combo_xxx" (or "cb_xxx"), every edit is "edit_xxx" (or (e_xxx). I try and do that oftentimes to help knowing the type of the controls I manipulate in the code. If you apply that with rigor (as every developer should :slight_smile: ), then getting the type of the control is just as simple as parsing the beginning of the name of the control (which I would prefer to the xml parsing aforementioned).

2 Likes
5

I'm sorry for the late reply.

Thank you very much for @PassThePeas’s response. The ideas you provided are great.

Actually, here are just some of the application scenarios, and there will be more needs in reality. If the official provides new feature support for it, there is no need to spend a lot of effort developing complex code. This is just my opinion, not that I am unwilling to design as you said.

Thank you again for your serious reply, I will close it.

1 Like