Calling a class from a script

Ignition
1

If I have created a class and saved it into it's own script within Ignition Designer, can it be 'imported' from another script in the same way as you could when writing 'py' scripts (i.e. placing all py's in the same directory and simply using the import command against the 'py' file containing the class to gain access to the class)?

If so, what would the construct of the filename need to be in this instance?

Say, for example, I nested it within a different sub-directory of the script library away from the sub-directory within which my script was in, how could I point the import command to it?

I've been looking through the knowledgebase and at Inductive University and I'm struggling to find any reference to the use of home-brew classes within Ignition.

It seems to work just fine when placed within the script it's used....however, as my class has been designed for use in multiple different circumstances, I suppose it really should be imported when required only to keep the script I'm using it within clean.

Cheers for any feedback

2

While you are in the script project library where your class is defined, just right click on the class on the right-hand side of the editor and select copy path. That will show you the full path to the class which is how you can use it in other script packages etc.

image

2 Likes
3

...and i just copy that and list it as an include at the top?

If so, that's cool...nice and simple.

I'd forgotten that was an option to be fair...my question was more along the lines though, as to whether an include would be tolerant of such a path.

I think it should be as I've just spotted some code used by one of our Dev's which suggest it would be.

Thanks again!

4

You shouldn't need to include it, just use the full path in the script where you need it.

1 Like
5

Ahh, you see, this is right in to the crux of my question.

I don't want to keep using the path to the script...I just want to use the methods within it.

This is where an include statement comes into it's own...declare it once, and, then refer to the methods many times throughout.

6

Edit: don't do this as pointed out below

import shared.scriptPackage.someClass as someName
someName.method()

1 Like
7

Sorry, you should not use import with project library scripts. There are odd corner cases that can eat your lunch. Use the full path everywhere you need it.

3 Likes
8

oh...ok.

Which 'corner cases' may these be then?

9

Misordered/unordered script loading that leaves old old code alive in strange ways. Never really nailed down, but suspected to be an artifact of java multithreading with jython's import machinery. Virtually impossible to reliably repeat, which is why I don't trust it.

It doesn't happen if you always refer to other project scripts' objects with full paths, at least for first use in a function.

5 Likes
10

do Python 'deconstructor' methods not work to close out these open threads then?

for e.g.:

del named class object

11

How about this ?

SimplerClass = SomePackage.SomeFile.SomeClass

foo = SimplerClass()
bar = SimplerClass()

Could that cause issues as well ?

12

No. You must .interrupt() them, and they must catch that, and exit voluntarily.

13

Possibly OK. Certainly OK if that first assignment is within a function call (to serve within the function) instead of at the top level.