ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)
-   -   Access to addon's table in OnInitialized callback? (https://www.esoui.com/forums/showthread.php?t=9196)

stolen6394 06/06/20 01:07 PM

Access to addon's table in OnInitialized callback?
 
Hi, I am a newbie writing my first addon and having a seriously difficult time and fun at the same time. :banana:

I'm not a native English speaker, so please let me know if what I wrote is unclear or misleading.

So here is the situation,

I made 4 files (two .lua, .xml and .txt)
and one of the .lua files makes a table (e.g., MYAddOnTable in the code below)
and the other one does what addons normally do (registering events... etc.)

the .txt file lists the files in the following order:
Code:

##... Title... APIVersion... etc.

MakingTable.lua
MyAddOn.xml
DoAddonJob.lua

In the xml:
Code:

... GuiXml... TopLevelControl... Backdrop...
    <Label ...attributes...>
        <Anchor .../>
            <OnInitialized>
                MyAddOnTable.foo()
            </OnInitialized>
....

I thought "since MakingTable.lua will be loaded first before the xml file is loaded,
so MyAddOnTable.foo() will be successfully invoked. great!"

but it turned out that MyAddOnTable is evaluated as nil at that moment.
I figured it out by modifying the code as follows:

Code:

<OnInitialized>
    FOO = 1
    BAR = MyAddOnTable
</OnInitialized>

and in the game, I typed "/script d(FOO)" and it said 1, (so the script must have been invoked anyway)
then I typed "/script d(BAR)" and it said nil. (meaning MyAddOnTable is evaluated as nil?)

I am confused. :confused:

Is there any way to get access to my addon's table in the OnInitialized callback?
or am I missing something?

Thanks in advance.

Dolgubon 06/06/20 02:14 PM

MyAddOnTable needs to not be local. My guess is that's what's going on.
A better way to check the value at that time than what you're doing, is to add pChat as an optional dependency, and then you can use d() directly within the OnInitialized tag.

stolen6394 06/09/20 08:13 AM

That really helped
 
Thanks to:

Quote:

Originally Posted by Dolgubon (Post 41417)
MyAddOnTable needs to not be local. My guess is that's what's going on.
A better way to check the value at that time than what you're doing, is to add pChat as an optional dependency, and then you can use d() directly within the OnInitialized tag.

I didn't know that d() comes from pChat. lol I thought the function is one of built-in log functions provided by ZOS. silly me.

The culprit was me that messed things up (of course there is no one but obviously me :banana:).

Here's the story:

I was writing an AddOn and feeling a mixture of chaos coming from the unfamiliar syntax of Lua and the pure joy of exploring this new area. Most of the time, I was testing some snippets by using "/script" command and copy the snippets to the AddOn if the test passed. Running "/reloadui" took soo long enough to get me exhausted, so I unloaded all the addons except for mine.

In the middle of the tests, I was tempted to make each UI controls access to the source code, instead of having them being accessed by the source code.

So I wrote "BAR = MyAddOnTable" in OnInitialized of the Label that I mentioned before.

And after some code works in lua, I got back to the xml, found OnInitialized of TopLevelControl empty, thinking "where is the code gone...? ugh...", and wrote "BAR = d(MyAddOnTable)" there in order to see if the result tells me it's a table, nevertheless, the Lable was where I supposed to see at the first place, not the TopLevelControl.

Since callbacks of OnInitialized are invoked in order from leaves to root (the moment that I figured this out is not far from the present), "BAR = MyAddOnTable" from Label was invoked first, and then "BAR = d(MyAddOnTable)" was invoked, overwriting with nil because I unloaded all addons including pChat.

Then I decided to post here with my English writing skills that are still taking over an hour for what I am writing now, so here I am.

Anyway, I am glad to learn things from this adventure.

Thanks.

Rhyono 06/09/20 08:21 AM

d() is not from pChat, but pChat lets it be used on init.

stolen6394 06/09/20 09:04 AM

where can I...
 
Where can I find that kind of knowledge? I feel a lack of information from the wiki. Even though it pours me a lot of texts such as a list of function names those are just names. I managed to figure out what they do from their name for some of them or tutorials thankfully, but no clue for the others. Please share your wisdom.

Baertram 06/09/20 10:07 AM

There is noone who will be writing all that down for free so don't expect to find ALL info somewhere :D
It's try and error, ask and try even more.

Even ZOs code does not provide documentation so you need to just "crawl and understand" it, or ask.
We have learned this since 2014 but still learn new stuff each day.

Rhyono 06/09/20 12:41 PM

It would take an inordinate amount of time to write it down and most of us are busy maintaining the addons we also aren't paid to do. Documentation is the most neglected part of programming and it's because it does not directly help with the task at hand (although it helps future people).

Drummerx04 06/10/20 11:42 AM

It would help to post the real contents of MakingTable.lua and MyAddon.xml, assuming they aren't stupidly large files. There are some interactions which aren't well explained in the ESO lua world which can result in nil values in odd places.
For example, every element created in xml files has a global variable binding which can conflict with your tables if you gave them the same name.

Another thing to check is whether or not you can just "/script d(MyAddonTable)" once your addon is loaded, this will show whether or not your table made it to the global scope in one piece.

Baertram 06/10/20 12:30 PM

I recommand using addons like "merTorchbug updated" or "zgoo" to inspect your variables.
/tbug MyAddon
/zgoo MyAddon

will show the results of your addon table in an own UI where you are able to scroll and inspect them -> jump to their depths or within mer Torchbug via the __index "link" to their "parents" (where parents are not the control's parent but the kind of object oriented "class" where this table was inherited from).
You will learn how the variables are tables, what contents they got, what functions they have and are able to use and where data comes from etc. even better if you use inspection addons.


All times are GMT -6. The time now is 08:47 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI