# TypeError:getComponent():1st arg cant't be coerced to int **URL:** \ **Category:** Ignition\ **Created:** [July 29, 2019, 3:57pm UTC](https://forum.inductiveautomation.com/t/typeerror-getcomponent-1st-arg-cantt-be-coerced-to-int/26958 "2019-07-29T15:57:58Z")\ **Posts on this page:** 1\ **Showing post:** 6
**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:** [July 29, 2019, 4:40pm UTC](https://forum.inductiveautomation.com/t/typeerror-getcomponent-1st-arg-cantt-be-coerced-to-int/26958/6 "2019-07-29T16:40:17Z")
> [@paul-griffith](#): > > In Ignition, we wrap all of our classes when we expose them to scripting, and we added an “overload” to `getComponent` that allows you to specify a single component’s name - but that breaks down if you ever get outside the boundaries of what we “expect” you to reach in scripting. If you want a detailed explanation, this thread might help, particularly the pitfalls and their work-arounds: > [@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/14): > > Ok, so I’ve been down the rabbit hole and found Ignition’s (undocumented) PyComponentWrapper. I haven’t deciphered it enough to be sure, but it seems to be invoked only for particular situations, based on the string constants in the class file (like “getComponent” and “getComponents”). To play with this, I constructed a conversion adapter like so: public class PyComponentAdapter implements PyObjectAdapter { public PyComponentAdapter() {} @Override public boolean canAdapt(Object jObj) { … Note that I wouldn't expect Kymera's PointLayer to take string lookups, so the wrapper is moot. --- _[View the full topic](https://forum.inductiveautomation.com/t/typeerror-getcomponent-1st-arg-cantt-be-coerced-to-int/26958)._