[Isomorphic]

Just access the ID property on the DataSource returned by getDataSource().

[Isomorphic]

Regarding your list of possible non-classes:

VisualBuilder and SelectionOutline are indeed classes. Not sure why they're on this list.
"TooLStripSeparatorEditProxy" appeared in the doc wrongly due to a typo we'll fix.

"EBay" shouldn't be there at all, we'll get rid of it.

WSRequest, FacetValue and ServerObject should all actually be @object, we'll fix that.

These are libraries of static methods which cannot be true classes because they need to exist before the Class system itself loads, so cannot be true classes:
isc
FileLoader
History

These are extensions of native JavaScript objects:
Date
String

For both categories, we could alter these to be @object, and add a new type of definition like @staticMethod, the equivalent of @classMethod but for objects. Would that work?

[kylemwhite]

VisualBuilder and SelectionOutline and all the others are on the list because in the Docs there is no 'extends Class' in the description as there is with most other classes that inherit directly from Class.



I have just noticed also that the description says 'for internal use only' so perhaps there shouldn't be any TypeScript representation at all. If so, could we put an attribute on those classes that are for internal use only so the generator will know to not generate anything for them?

For libraries of static methods: Yes, marked as object with staticMethods seems more appropriate and would help the generator do the right thing (i.e. it will know not to add 'extends Class').

For the extensions of native JavaScript objects: Could we mark them as something different? The reason being that they need to be handled differently than classes and objects. Classes and objects become interfaces with the same name in TypeScript (and also the _Static and _Props versions). For the extensions, so far I've only dealt with Array (manually) and it seems to be working (altough it is not complete) so I'm assuming Date and String will be similar. This code is near the top of the isc.index.d.ts file:

/**
 * Generic extensions to JavaScript Arrays. You can call these on any Array.
 * JavaScript's native Array is retrofitted to support the List API (not implemented yet).
 */
interface ArrayConstructor {

    isLoading(value: any): boolean;
    compareAscending(first: any, second: any): number;
    compareDescending(first: any, second: any): number;

} // Array

If there were some way to identify these, then the generator could automatically do the right thing (i.e outside of the Isc namespace and appends Constructor to the name) without maintaining a list of special cases.

[kylemwhite]

Did method:ListGrid.getDataSource get removed?

[Isomorphic]

Looks like there was a merge problem and last night's build went out with some changes reverted, including the addition of getDataSource() docs. Already corrected for tomorrow's build.

[kylemwhite]

General question: What is the proper way to set a Class API property that does not have a setter?

Example, I am trying to set the AMIndicator (and PMIndicator) property on the Time class. According to the docs, it is writable but there is no setter and there is no setProperty() method on the Time static class nor the Class static class. So, what is the proper way to set it?

[Isomorphic]

These are generally attributes for internationalization, which would be set once ever, right after the framework is loaded and before any other application code runs. They are set via [targetClass].addClassProperties().

[Isomorphic]

You may have noticed a ton of additional fixes going in, in particular, we've cleared up a bunch of instances of string-based types (like Identifier) which were described in prose as strings but not explicitly declared to be strings, attribute vs setter disagreements which could not be programmatically reconciled, etc.

There's one additional item in Errors.txt we can't figure out - what's this? There's nothing we can find in referenceDocs.xml that looks like this.

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

[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.

[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?

[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]

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.

[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]

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]

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.