I’m trying to make better use of / understand the scripting abilities of Ignition. Is there a comprehensive list of extensions and lists associated with the various HMI items?
For example what all can I do with a container? Is it different than the root container? What about the main window? I understand that it makes use of Jython, but that some names have been augmented and some features have been added, but where is it all documented?
This section of the user manual describes component scripting in general. More information is found in the appendices, for specific components, and for the built-in scripting functions.
That’s what Inductive Automation supports. To go beyond, you need to understand Swing, the java user interface library. Or at least be willing to poke around in its API Reference. Toss in java reflection, and you can discover a great deal about the inner workings of the Ignition platform. This topic can help you get started with reflection.
I guess if that’s all that’s available, then that’s all that’s available, but I was hoping for something a little more definitive.
I.e. Every container object has these extensions:
.blah
.bleh
.meh
Every Window object has these extensions:
.something
.or
.other
[quote=“abishur”]I guess if that’s all that’s available, then that’s all that’s available, but I was hoping for something a little more definitive.[/quote]I guess you and I have different ideas of “definitive”. Ignition is built on top of Java Swing. Every single Ignition component inherits all JComponent properties and methods. Every single Ignition container is likewise an Abstract Windowing Toolkit Container, with all of its properties and methods. Ignition adds more properties and methods for specific objects, for which they document the features they are willing to support.
I get what you’re saying, but a centralized repository would be beneficial for individuals like myself who are not familiar with java swing.
I mean take the Window property .getRootContainer(). It’s nowhere in either link you provided nor the official documentation and doing a google search of the entire docs.oracle.com site gets some hits on it for Fusion middleware but they seem unrelated maybe?
The only reason I even know that property exists is because I happened to come across it here in the forums. Having a centralized repository that says “this method exists!” even if it was just a hyperlink to an externally maintained site such as you provided would go leaps and bounds to providing a better understanding of what we’re working with for people like myself who are familiar with programming, but unfamiliar with Java.
[quote=“abishur”]I mean take the Window property .getRootContainer(). It’s nowhere in either link you provided nor the official documentation and doing a google search of the entire docs.oracle.com site gets some hits on it for Fusion middleware but they seem unrelated maybe?[/quote]It’s documented as the rootContainer property of Ignition windows, the NetBeans abbreviation for the getRootContainer() method. Jython creates those property shortcuts for users when it finds getter and setter methods on a java object accessed from jython. You claim programming familiarity below so I hope I don’t have to explain getters and setters.[quote=“abishur”]The only reason I even know that property exists is because I happened to come across it here in the forums. Having a centralized repository that says “this method exists!” even if it was just a hyperlink to an externally maintained site such as you provided would go leaps and bounds to providing a better understanding of what we’re working with for people like myself who are familiar with programming, but unfamiliar with Java.[/quote]The Ignition user manual does link to external python and jython sources, which lay the foundation for using scripting in Ignition. And the Ignition Manual does have property and method explanations per component type for the features IA supports. I’m going to go out on a limb here and guess that the undocumented features are undocumented because a programmer has to have some grasp of java and swing to use them safely.
I will state at the outset of this missive that there is no doubt Ignition can readily be used out of the box to create very powerful systems without an in depth knowledge of Swing or Python/Jython, and, I am not implying an in depth knowledge of same is required to effectively use Ignition.
I have been developing in Ignition for about six years. (Prior to Ignition, the primary environment I had used for years was C and its variants ++,#). However, after perusing the forum and reading the responses, I had questions of ‘how did he/she know to do that?’, or more so, ‘what or why is that?’. There a two references that I recommend to help one get some answers and a better understanding of the overall Ignition scripting environment and architecture. 1) ‘Python in a Nutshell’ author Alex Martelli and 2) ‘Java Swing’ authors Low,Eckstein,Wood,Elliott & Cole. Both are published by O’Reilly. It is absolutely not necessary to have and understand these references to use Ignition. I found the references to be invaluable resources in my understanding of the power Ignition literally puts at your fingertips.
Thanks Mark, I appreciate the resources suggestions.
I obviously think that's asinine 
the fact that there are abbreviations for existing methods (but the non-abbreviate methods also work) is exactly what I'm talking about. I completely missed that one page that talked about one specific usage example precisely because there is no centralized page that discusses common scripting methods for specific elements. It's too decentralized and makes fully utilizing the underlying power of Ignition difficult for newcomers to Java like myself.
Even for experienced Java users I fail to see why such a help page would be a bad thing or something you'd want to resist? I mean what benefit is there in saying, "Well the methods are spread out through the existing help document, but you have know what they're called to find them, so let's keep things the way they are?" instead of saying "Hey, yeah, a single page for each individual component under the advanced scripting section would be extremely useful for rapidly referencing of supported methods" 
[quote=“abishur”][quote=“pturmel”] I’m going to go out on a limb here and guess that the undocumented features are undocumented because a programmer has to have some grasp of java and swing to use them safely.[/quote]I obviously think that’s asinine 
the fact that there are abbreviations for existing methods (but the non-abbreviate methods also work) is exactly what I’m talking about. I completely missed that one page that talked about one specific usage example precisely because there is no centralized page that discusses common scripting methods for specific elements. It’s too decentralized and makes fully utilizing the underlying power of Ignition difficult for newcomers to Java like myself.[/quote]I strongly disagree about the safety of using the underlying java, particularly the material discovered via reflection. It is absurdly easy to crash the designer or client, or corrupt the project you’re working on so you can’t open it again. Pretty good reasons in my book for IA to leave it to the forum. I’ve attached warnings to some of the techniques I’ve posted on these forums because I’ve been there and done that.
IA has documented the very few common (supported) scripting methods in the manual section I linked. There simply isn’t anything else common except for the Swing stuff underneath. IA has substantial detail on per-component properties and methods in the appendix I pointed out, which you also seem to have missed. I’m not going to say IA’s manual has everything I think should be there, but they’ve chosen what techniques they want to support.[quote=“abishur”]Even for experienced Java users I fail to see why such a help page would be a bad thing or something you’d want to resist?[/quote]Experienced java users actually read javadocs, a standardized documentation system. My pointer to the Swing part of Oracle’s javadocs answers your questions about common methods that IA left out of their manual. Why should IA re-document what Oracle displays publicly to all who visit? (But copyrighted – so no importing into IA’s manual, except for tiny fair-use snippets.)[quote=“abishur”]I mean what benefit is there in saying, “Well the methods are spread out through the existing help document, but you have know what they’re called to find them, so let’s keep things the way they are?” instead of saying “Hey, yeah, a single page for each individual component under the advanced scripting section would be extremely useful for rapidly referencing of supported methods” 
[/quote]You’re asking for a magic cheat sheet. Sorry, it’s not that simple. The methods are spread out because they differ from component to component, as I’ve pointed out. There’s no need to document all the getters and setters because you don’t need them in Jython – you have the corresponding property to use.
Understanding Swing, even a little, would answer your questions. I’ve suggested some reading towards that end, and Mark has suggested some other reading towards that end. Mark is clearly nicer than I am, or you’ve just managed to push my buttons, so I think I’ll let others carry this topic forward.
Actually, I really wish we did the opposite -- documented the getters and setters, not the properties. As Ignition gets more and more complex, the getters and setters are doing more and more behind the scenes and are more likely to leave your component in a consistent state.
Um, what? Jython calls the getter when you use the property, and calls the setter when you assign to the property (of a java object).
We had a discussion on that here. 
The consensus was that it usually happens, but there are a few cases where it isn’t happening. Going forward, we’ll try to make that 100%, but we aren’t going to go back and search for places where it’s breaking.
[quote=“KathyApplebaum”]We had a discussion on that here.
The consensus was that it usually happens, but there are a few cases where it isn’t happening. Going forward, we’ll try to make that 100%, but we aren’t going to go back and search for places where it’s breaking.[/quote]Interesting. Let me guess… when there’s a public field with the same name as the property, it has priority over the getter/setter? { Quick googling … } Yep, per “Python in a Nutshell” 2nd edition, ch. 26. Is there any reason you can’t use reflection to find all such cases in your whole codebase?
Yes, yes, and I'm no true Scotsman either 
sigh I guess we're just no getting through to each other, because I'm not asking for some magic cheat sheet, I'm asking for basic documentation for whatever corresponding property you're mentioning in a centralized format as opposed to spread through the help documents or whispered from the shadows in hushed tones. Such as this one from Wonderware. Yes, the information on the methods is often horrible, but it's at least a common centralized resource for me to reference when I swing back to doing work for Wonderware after working on Ignition, iFix, FactoryTalk, etc.
Here, let me try to reach a middle ground point.
It would be very handy if all the various methods and exposed extensions already referenced in the existing user manual were coalesced into a single appendix and grouped into appropriate categories. I.e.
Mostly Global:
getParent() - returns the parent object of the component
Windows:
rootContainer() or getRootContainer() - gets the root container of the window object
Labels:
.text - the text value of the label component
and so forth and so on.