onInit and merge=join

[Varsuuk]

I'm sorry, I'm sure this kind of thing has been covered ad nauseum but on a quick search - I could not spot it.

In past work I was adding stuff and not needing to work with onInit for the xml gui stuff. So didn't give this thought.

If I need to add something to an existing windowclass and do not want to copy it all (from MoreCore), I did merge with my changes but I needed to make some of the controls defined in "super" class invisible (or even in the leaf) - I thought this would need to be done in onInit (and updates maybe) - I think I have a different angle as I write this to think on - but assuming it don't pan out and just to learn anyhow:

What does one do if you want to add/decorate a "parent" (sorry if misusing words for this) windowclass in one that is adding or removing functionality ... a super.FUNCTION(), if you will (although I guess it isn't actually derivation... dunno)

ie: can I get the onInit or onUpdate in "newer" class to be called yet STILL do the work from "older" or do I need to copy all the code over?

[Varsuuk]

OK - was able to get around it by putting the <script>setVisible(false)</script> in the actual control inside the new windowclass

but this means it starts correct, but later not sure how I can force the onUpdate since this is in the "newer" windowclass without hacking... maybe will get more realizations but dunno.

[damned]

If you are changing only a few things you should merge.
If you are changing a lot you might be better off cloning the whole file and then editing it directly and merge=replace the file?

[Varsuuk]

Yup figured. M not changing much at all. Problem is, I need to do some thing “onInit()” as far as I can see.

My mind has trouble with this because I keep wanting to think of it as inheritance. Which it isn’t.

I figured out how to make initialize the controls to make them invisible without requiring onInit(). But not sure how yet how to use the OptionsManager to control the controls. I cannot have onInit to register a callback in the “new” windowclass - since doing so fubars the parent. I guess I copy it all. I really do not want to support so much functionality via copying it. I’d much rather just code the changed pets. But with my limited experience I don’t see how that is possible.

This is intended as a small project to get some people started so it won’t be too bad if I just never update if the morcore’s main sheet gets updated can use an earlier version unless the update is due to corerpg triggering.

It I’ll cross that bridge if it comes. This is not my “labor of love” it’s a practical thing I can do fast first and I can jettison it if support becomes an issue.

Gracias - I’ll just take my record_more.cml and make the changes direct on a copy of morecore’s entire file of same name.

[damned]

If you are adding/editing the <script> at the top of the file Im pretty sure that will over write the script in the base file. I think only the one version will be executed.
So copy that whole <script> code and edit it to suit.
Keep going with the merge="join" and the minimum changes.

[Trenloe]

Use super.onInit in your new XML to call onInit higher up the merge layers.

Info here: https://www.fantasygrounds.com/forums/showthread.php?58755-ct_entry-lua&p=516228&viewfull=1#post516228

[Varsuuk]

Ugh, no wonder I kept thinking super (as in Java) - I know remember WRITING code last year which did if super.foo then...

I have to apologize, I have neurological memory issues, that's why this time around I am hugely taking notes on anything in my OneNote as I lookup stuff. On which this topic gets an entry.

Thanks /blush... I KNEW there had to be a way for this to work. I'll clean it up tomorrow. Got it to work a messier way. Gonna post a heads up on the name==source comment I made earlier (once I find it) since I got bit just now on that.