-
January 26th, 2020, 03:20 #1
Not sure why adding onInit() to rollable control kills the die icon?
Any idea what is messing up the "rollable" icon on this control if in the script attached to it I simply add an onInt() method - even if it is empty?
The control, number_savingthrow_monster, works fine in both cases, rolling. However if the onInit() is added, away goes the 20sided dice icon. It's weird - I don't get the angle here.
Code:<template name="number_savingthrow_monster"> <number> <frame name="frame_charsheet_savingthrow" offset="7,5,7,5" /> <anchored width="32" height="20" > <top parent="**MISSING ANCHOR**" anchor="bottom" offset="5" /> </anchored> <nokeyedit /> <rollable /> <script file="campaign/scripts/monster_saves.lua" /> </number> </template> ... <number_savingthrow_monster name="savingthrow"> <anchored width="32" height="20" > <top parent="columnanchor" anchor="bottom" relation="relative" offset="7" /> <left offset="97" /> </anchored> </number_savingthrow_monster>
-
January 26th, 2020, 04:25 #2
This happens because "number" is not a base control (it's not in the API documentation), it's a template based on the numberfield control. Search for that template in CoreRPG and look at the attached LUA script - the onInit of that script sets the rollable icon. As you're defining a new onInit function in your template based on the "number" template, you're overriding the onInit function in the "number" template.
Use the following code in your layered template onInit function to call the higher level code:
Code:if super and super.onInit then super.onInit(); end
Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!
-
January 26th, 2020, 04:47 #3
Great, I was on a roll (no pun intended) adding various fields in the NPC UI. I did a quick search on WEB basically of "lua calling parent method" and got bunch Lua style "oop" stuff which I read once long ago when reading the Lua Ref book and I knew our version didn't do this. So since I was paying like 1/8 of my attn on the search, I thought hmmm guess that is't it - we don't have a way to call parents because... didn't think it through, of course we can
In this case, I didn't need to do much in there - was just for some debugging and testing so removed it to go on - will return it later and thanks on the super() memory
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks