[kylemwhite]

RichTextItem defines the colSpan property defining it as number | string. This overrides the base FormItem colSpan which is defined as simply number. I understand that sometimes there is a reason to override a property with a different type but in this case is there a reason? Same goes for ToolbarItem.

[kylemwhite]

Same thing with RelationItem, ScrollingMenu... referenced as base classes but not documented.

I'm getting close to 100% class coverage.

[kylemwhite]

BooleanItem extends CycleItem but CycleItem is not documented.

[kylemwhite]

There's a class called MathFunction with a couple static methods (getDefaultFunctionIndex(), getRegisteredFunctionIndex ()) that return an 'Index' but there is no documented type (or object or class) called 'Index'. So, what is an Index?

[Isomorphic]

Technically not needed since it is a setter, hence can be called via setProperty("data"). But for clarity we'll add a short doc for it.

[kylemwhite]

This page: http://www.smartclient.com/smartclie....TileGrid.data says that the setter for TileGrid.data is TileGrid.setData(). However, there does not seem to be a TileGrid.setData() in the docs. Is it just missing from the docs?

[Isomorphic]

There are ListGrid, TreeGrid and DetailViewer fields, but these do not have subtypes. There are also some cases in which it would come up in the Dashboards and Tools system. We would recommend discussing it as needed for DF.items, but applicable to other cases, such as where Canvas Properties are specified and you want to use type-checking for ListGrid properties.

[kylemwhite]

Agreed, should be in the TypeScript documentation. Is this just one case of a more general rule though? I seem to recall (but not specifically offhand) that there are other things that are created by defining an array of plain old JavaScript objects, some of which might have specific types associated with them.

[Isomorphic]

Instantiation of FormItem subclasses is never correct, and may appear to work superficially for some items but will always lead to failures.

That TypeScript approach seems perfect for this situation. You had a little intro doc - this would be a great place to point out that approach. Probably best to say that you only need it if you happen to use a property that is specific to the particular FormItem type you are using.

[kylemwhite]

Understood instantiation is bad form in this case. BTW, it did work for SelectItem but not for ButtonItem. Even though I did isc.ButtonItem.create(), I got a text box.

This syntax works with TypeScript and gives type checking without using .create():

  isc.DynamicForm.create({
      ID:"exampleForm",
      width:450,
      fields: [ 
          {
              type:"select",                  // <-- Should probably still do this, although it works without it.
              title:"Select Multiple (Grid)",
              multiple:true,                       // <-- Works because multiple is a property of SelectItem
              multipleAppearance:"grid",
              valueMap: [ "Cat", "Dog", "Giraffe", "Goat", "Marmoset", "Mouse" ]
          } [B]as isc.SelectItemProps // <-- This gives us type checking in TypeScript[/B]
   
          ,{
              type: "button"      // <-- Will not work without this, produces a textbox cuz SC doesn't know it's supposed to be a button unless we tell it.
              , title: "MyButton"
              , startRow: false  
              , endRow: false                                                                     
              , click: (form: Isc.DynamicForm, formItem: Isc.FormItem): boolean => {
                  // Do something;
                  return true;
              }
          } [B]as Isc.ButtonItemProps // <-- This gives us type checking in TypeScript[/B]

[Isomorphic]

type:"select" works for backcompat reasons. editorType:"SelectItem" is correct usage, or using "enum", which is actually a data type for which SelectItem is the default choice.

Manually instantiating a SelectItem is indeed bad usage. Is there no way to assign type information to an anonymous object in TypeScript, other than to make it a method parameter? If it's the only choice, there could be a set of functions like "cast.SelectItem" that do nothing but return what's passed. This might be useful in other situations, such as places where Canvas Properties are allowed, but the developer needs to pass ListGrid properties and would like type safety.

[kylemwhite]

FormItems are tricky - they pass through properties to the underlying FormItem type. In the code you pasted you see that you specified type: "select" and that in turns treats the item as a 'SelectItem' - which in the docs does have a 'multiple' property defined.

Understood, although that does bring up another small issue. According to the docs, the type property is of type FormItemType which is a union of strings. However, there is no "select" option. There is, however, an "enum" option and it produces a SelectItem. So, should "enum" be renamed to "select"? Or maybe "select" needs to be added..... oh, wait, never mind. I see now that it can also contain the class name of a FormItem, but shouldn't this be "SelectItem" instead of "select"? Why does "select" work? It's not in the list and it's not a classname.

For TypeScript, I will use the following approach which bypasses the above issue and works:

isc.DynamicForm.create({
    ID:"exampleForm",
    width:450,
    fields: [ [B]isc.SelectItem.create([/B]
        {
           [B] //type:"select",[/B]                  // <-- No longer needed because this is defined as a SelectItem already
            title:"Select Multiple (Grid)",
            [B]multiple:true,                       // <-- Works because multiple is a property of SelectItem[/B]
            multipleAppearance:"grid",
            valueMap: [ "Cat", "Dog", "Giraffe", "Goat", "Marmoset", "Mouse" ]
        }[B])[/B], // ....

Edit: I just discoverd this

FormItems are never created via the create() method, instead, an Array of plain JavaScript objects are passed as DynamicForm.items when the form is created.

from: http://www.smartclient.com/smartclie...rch%3DFormItem

Which makes me wonder if my new approach is valid.

[jaredm]

However, in the docs (and thus in the TypeScript library), the FormItem does not have a property called multiple. Can that be added?

FormItems are tricky - they pass through properties to the underlying FormItem type. In the code you pasted you see that you specified type: "select" and that in turns treats the item as a 'SelectItem' - which in the docs does have a 'multiple' property defined.

[kylemwhite]

Version 2017-07-09

In several examples, a DynamicForm is created by passing an array of FormItems like this:

isc.DynamicForm.create({
    ID:"exampleForm",
    width:450,
    fields: [
        {
            type:"select",
            title:"Select Multiple (Grid)",
            [B]multiple:true[/B],
            multipleAppearance:"grid",
            valueMap: [ "Cat", "Dog", "Giraffe", "Goat", "Marmoset", "Mouse" ]
        }, // ....

However, in the docs (and thus in the TypeScript library), the FormItem does not have a property called multiple. Can that be added?

[kylemwhite]

Yes, I have noticed and I've highlighted the improvements in the spreadsheet (https://github.com/kylemwhite/isc/bl...csMetrics.xlsx). It's looking much better, thanks.

For that particular issue, the formatting was messed up so it did not list the ref attribute. I've fixed that now:

Methods with one or more parameters missing a type: 1
1. classMethod:isc.setAutoDraw, ParamName=enable, type=

In general I try to print out the ref attribute so that it's easy to search in the xml file. If you see anything else missing the ref attribute, let me know and I'll fix it right away.