JSDoc Form Warnings

Classic Servoy
1

Hi

I am getting a load of warnings where forms are being referenced from other modules as follows

forms.section_temps.elements.headerbar.bgcolor = ‘yellow’;

Multiple markers at this line

  • The property section_temps is undefined for the type Forms<cdm_mod_security>
  • The property section_temps is undefined for the type Forms<cdm_mod_security>

I am fairly certain this is to do with the JSDocs, if so can anyone tell me how you define a form from a remote module in the current method JSDoc ??

Essentially my warnings list is growing and most of the issues are to do with the JSDoc element which I am keen to resolve as I go along rather than after the event.

Many thanks

2

This most likely means that you’re referencing a form is a parent module, instead of one in a child module.

Modules are not aware of their parent (the solution/module into which they are included), only of their children (the solution/modules included into the module). Thus, if you reference forms in they parent module, the build process cannot resolve the reference and generate a warning.

Paul

3

Thanks Paul, that makes sense - I will try turning around the structure as it should be relatively simple and perhaps that will fix the issue. Ideally I want to get to the end of the project with no warnings !!

Cheers
Gordon

4

Paul

On further investigation how is it possible to create a module based solution without at some point creating the warnings about un defined forms etc. Surely even in a cascaded type scenario there are some instances where the module needs to reference the parent and hence will be unaware of the form it communicating with ??

5

if you need to reference back from a module to some main solution, without warning, do something like this:

forms['myform']['mymethod'](arg0,arg1)

so type everything fixed as text.

6

While Harjo’s suggestion is a possible way to get rid of the warnings, it is not the correct way IMHO, as it’s basically a workaround: by using strings Servoy just stops validating your code

A module should not depend on its parent ‘at designtime’. The the ‘at designtime’ I mean that Harjo’s suggestion makes a hard link from the module to the parent in the codebase. Instead, if there is the need to let code in the module operate on objects that are in the parent solution, the parent solution should “register” itself or it’s objects with the module at runtime.

For example: where ever you have this code:

forms['myform']['mymethod'](arg0,arg1)

you instead create (public) variables for the formName and methodName in the module (or you can hide the actual variables and use public setter functions for it) and the the code becomes:

//code inside a form in the module
var formName;
var methodName;
if (formName && methodName)
forms[formName][methodName](arg0,arg1)

//code inside the parent solution, for example in the onOpen event handler method of the solution
forms.theFormInTheModule.formName = 'myform';
forms.theFormInTheModule.methodName = 'mymethod'

There are of course many variations to this approach, like the already suggested hiding of the variables and exposing setter functions to set the variables or instead of setting the form/methodName you can pass references to objects like forms of methods around. When the latter is done, one has to take care when storing the references. Especially when it comes to references to forms of objects related to the form, like elements of form methods: Forms can be unloaded automatically, thus invalidating the reference, hence it’s advised to never store references to forms/form objects.

Hope this helps,

Paul