Suggestion: Check inheritance chain for TNBehavior on error.

[RFCsDriveMeNuts]

I was "homebrewing" TNBehavior, before I learned that TNBehavior existed and ran into it not finding RFC calls, even though it previously had (order issue I presume).

If you expect or recommend users to use TNBehavior, when a RFC not found error occurs, I'd suggest doing a quick iteration down the inheritance chain to see if it contains a TNBehavior.  If not found, throw a warning or error, stating that you force/recommend the user to use TNBehavior.  If you want to leave it as a choice, mention in the warning to flip the TNObject.rebuildMethodList bool to true.

It should alleviate some of the questions before they come to the forums begging for help, like me :-).

[ArenMook]

TNBehaviour is just a convenience script that lets you use the 'tno' shortcut instead of having to cache TNObject yourself. You don't have to use it if you don't want to, or if you have scripts derived from some custom class of your own.

[RFCsDriveMeNuts]

I understand.

But TNBehaviour does do one thing that is very important besides give access to TNObject: set rebuildMethodList to true.  Without that, your RFCs will not work reliably (it seems to dependent on the component execution order?).  By checking the inheritance hierarchy, only on errors related to missing RFCs (obviously you don't want to always check for optimization reasons), you can educate your customer: use TNBehaviour or set rebuildMethodList to true manually to ensure RFCs work.  The customer can then fix their own bugs quickly, and learn about your library in the process.  It never hurts to give a programmer too much information on how they screwed up!

I hope you're not offended by my suggestions.  I have felt inspired since you implemented one of my first suggestions.  I am not trying to redesign your library, as it is very good and clearly I love your work.  I am simply suggesting additions I've put in for myself, that I think other people may enjoy and find useful.  Most of my suggestions merely guide the customer when they make mistakes, like this suggestion.

[ArenMook]

Not at all, constructive criticism and/or suggestions are always welcome, and it's always good to better understand how other users approach and use the library and what confuses them.

The rebuildMethodList flag is one of those things I haven't even thought about for some time -- but good point. It does indeed depend on the script execution order, and setting that flag to 'true' on the TNObject forces the TNObject to re-evaluate its RFCs. You will want to do this whenever the list of RFCs changes for any reason (component gets added or removed).