# Binding to Custom Component Methods

**URL:** <https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245>\
**Category:** Ignition\
**Tags:** scripting\
**Created:** [August 14, 2018, 4:58pm UTC](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245 "2018-08-14T16:58:24Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 14, 2018, 8:20pm UTC](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245/6 "2018-08-14T20:20:19Z")

</div>

Note that when you get down in the weeds, various Swing methods that might yield a component for you will deliver it shorn of its custom methods and custom properties. The generic solution is presumably planned for a future version of Ignition, but the current version of Simulation Aids installs the necessary shim to prevent this from happening. See the discussion here:

> [@Transaction groups triggered expression item updating when trigger is false](http://forum.inductiveautomation.com/t/transaction-groups-triggered-expression-item-updating-when-trigger-is-false/17196/12):
>
> Interesting. That means custom methods behave like custom properties in java-to-jython conversions. So, Java objects have to be wrapped in jython shells to be used within the jython interpreter. The standard java-to-jython shell exposes the methods as-is and also takes any methods that fit the NetBeans getter/setter naming conventions and exposes those as the corresponding properties. Ignition overrides the standard conversions so that its components have their custom properties and methods …

---

_[View the full topic](https://forum.inductiveautomation.com/t/binding-to-custom-component-methods/19245)._