thousands error/warning servoy 6

[Juan Etec]

Hi,
I am testing servoy 6.0 with a solution who work in servoy 5.2.8.
I export my solution from 5.2.8 and import in servoy 6.0.
An than appears only 16 error and 4200 warning.
Some of them are under control, but another are difficult to know the problem.

Some difficult error:
-A cycle was detected in the build path of project: Example

- If in a relation I use a global variable from another module from the same application :Relation "xxxx_to_yyyy" has a primary dataprovider "globals.variable" which is not found.

-If I use a relation who source an destination have a table but in the 'FROM' column has only a global variable and I use that in a Form who his dataSource is none: Relation "_to_articulos$sn_tree_id_selected" has a primary dataprovider "globals.sn_tree_id_selected" which is not found.


Some difficult warnings:
-The property tipo is undefined for the type JSRecord

if I has that code, how can I define that record?

Code: Select all

* @param {JSRecord} record
   *
   * @returns {Boolean}
   *
   * @properties={typeid:24,uuid:"E3542176-DBCB-4251-B5F3-892F4B35B564"}
   */
       function factura_onRecordInsert(record) {
   
      record.tipo


-I use to call a lot of method from my solution to a module and it give me a warning, the same problem with global variable: The property utl_dato is undefined for the type Globals<MySolution>

-The function sn_guardar() is undefined in this script

Code: Select all

function sn_guardar(_no_editable) {
            return _super.sn_guardar(_no_editable)}

[jdbruijn]

Hi Juan,
Seems you have some work to do
I had about 1200 warnings and 2-3 errors.

I can give you hints on the folowing 2 warnings, the others I haven't come across.

-The property tipo is undefined for the type JSRecord

I think you can define which datasourse the record is from:

Code: Select all

* @param {JSRecord<db:/server/table>}

-The function sn_guardar() is undefined in this script

Check if the super function has its parameters defined.

Greetinx,

Jos

[Juan Etec]

Hi Jos,
thanks for your answer.

Yes the second answer the problem is what do you say to me.

[pbakker]

If you have a cycle in your buildpath, it means that solution/module A includes solution/module B, which in turn includes solution/module A again. This is not a best practice, a solutions module structure should be a tree like structure.

You can lower the Problem market level from Error to Warning here: Window > Preferences > Dynamic languages: Build path problems

[Harjo]

I'm still a bit confused about this cycle detected, module including thing....

In Servoy 3 it was common knowledge to have a module, that contains, every relation, calculation, common used images, etc...
So if we created a new module, like invoicing, we included this core_module so that we have immediately access to all this stuff.
Also, the main-solution (our CRM) includes this core_module, and also our main-solution, includes ofcourse the invoicing module.

And now we have got an error, that a cycle is detected.. why? I understand the warnings, that if you have images, or formnames, with the same name,....

As far as I know, Servoy flattens everything down, so why is this a risk?

[Karel Broer]

I'm still a bit confused about this cycle detected, module including thing....

In Servoy 3 it was common knowledge to have a module, that contains, every relation, calculation, common used images, etc...
So if we created a new module, like invoicing, we included this core_module so that we have immediately access to all this stuff.
Also, the main-solution (our CRM) includes this core_module, and also our main-solution, includes ofcourse the invoicing module.

And now we have got an error, that a cycle is detected.. why? I understand the warnings, that if you have images, or formnames, with the same name,....

As far as I know, Servoy flattens everything down, so why is this a risk?

Same question here. Our modules use functionality from eachother, but are maintained separatly

[jcompagner]

I think i have explained this already, but circular references don't make any sense
At the moment you have that then it is just one project

The error you see is from Eclipse itself, not something we do. Why? Lets just say that you need to build your solution... You have there 2 modules A and B now we need to build/check them
Which one should be first to build? A or B? Because A says i depend on B but B says no i need A...

There are all kinds of hacks for this to not go into a stack overflow because of this, but in the end it is just not something what you should do.

For example would you do something like this

Form A extends Form B
and Form B extends again Form A

thats what you are doing....

Modules should work standalone, but now if you just want to work on a single module and you activate that one, you just activate everything again.

If you now also would use that module in another solution, what you do is include everything again, so you simple other solution also depends on your big main solution..

[Harjo]

Oke I understand that, but now my example above.

So, we need in every module, some core, relations, globals, images for buttons, etc..etc..
Do we REALLY have to import them or recreate them again, in every module? This generates, a bunch of warnings, because you have the same relations-names, images-names etc..etc.. than we REALLY have to rename or prefix them again, for every module?

Is'nt this a HUGE overhead??

[tysonj]

I feel the below link would help you
http://forum.servoy.com/viewtopic.php?f=3&t=13602

[ROCLASI]

Hi Harjo,

You can use your common submodules just fine. These should not give any cycle warnings. It's the 'Link module' methodology that will cause this.
And in the end they are just warnings, not errors. So it's not really a showstopper.

[Joas]

In Servoy 3 it was common knowledge to have a module, that contains, every relation, calculation, common used images, etc...
So if we created a new module, like invoicing, we included this core_module so that we have immediately access to all this stuff.
Also, the main-solution (our CRM) includes this core_module, and also our main-solution, includes ofcourse the invoicing module.

So this looks like this:

Code: Select all

    MAIN
      |
    __|_____
   |        |
CORE     INVOICE
            |
           CORE


Here you don't have a cycle, it would only be a cycle if one of the modules includes one of it's (grand)parents.

So if you have a cycle, then it must be that also one of the following is going on:
-CORE includes MAIN or INVOICE
-INVOICE includes MAIN.

[Harjo]

Ahhh, Joas, YOU put me on the right track!

I thought indeed, that I had such structure, but one module indeed, included the main-solution, which was not needed.
I'm happy now!