Deinitialize Slab

[flamendless]

Hi, in cases where there are multiple Slab initialized/used (i.e when switching from one state to another), Slab hangs the system upon exit.

I am still unsure of how this weird behavior happens as my project is very complex. I think that when multiple files/states uses Slab causes the issue (though they are not processed at the same time).

[coding-jackalope]

Hi @flamendless, are you calling Slab.Initialize multiple times? This should only need to be called once in love.load. What is the context of your situation where this needs to be called multiple times?

[flamendless]

Upon further testing, the problem is not with multiple Slab.Initialize call.

It seems that when there is loaded frames in the previous state and then switching to another state as well.

Im also testing whether it has something to do with the widgets themselves.

[flamendless]

This is getting tricker, I've tried:

• Both State A and State B has the same system I use for debugging (which uses Slab)

Test 1:

1. State A has Slab.Initialize call
2. Switch to State B (which also has Slab.Initialize call
3. Quitting on State B hangs the game

Test 2:

1. I've removed the Slab.Initialize call in State A (still has the Update and Draw of Slab)
2. Switched to State B (has Initialize, Update, and Draw)
3. Quit in State B, no hang up.

Test 3:

1. Removed the debugging system in State A. Retained Initialize, Update, and Draw
2. Switched to State B
3. Quit in State B, did hang up

Test 4:

1. Completely moved Slab.Initialize to the debugging systems' init method.
2. Moved Slab.Update and Slab.Draw to debugging systems' update and draw method
3. Only call debugging system's update and draw in State A and State B
4. Switching to State B then quitting still hangs up the game.

[flamendless]

Does Slab store data/internal state dependent on the client's usage? Like storing ID and data Slab widgets need? Maybe there should be a flush method where all of those will be cleared up.

[coding-jackalope]

Hi @flamendless, thanks for looking into this. Slab does store some state information for the various controls based on the ID given to those function calls. However, Slab should not need any additional information from the user and will only act on the data when the function is called. There is some validation that occurs for windows prior to drawing the requested windows and controls.

I am still curious though why multiple Slab.Initialize, Slab.Update, and Slab.Draw is being called. Slab.Initialize should only be called a single time through the love.load method. Slab.Update should only be called from love.update once per frame and Slab.Draw should only be called from love.draw once per frame. The Slab.Draw call should be made at the end of your draw loop.

love.update -> Your Game Update -> Slab Update -> Slab Function Calls
love.draw -> Your Game Draw Calls -> Slab Draw

Slab.Update should be called at the start of your debugging system. Any other states within that system should not need to call this function again. Any Slab function calls after this Update call should work fine. And these states should not need to call Slab.Draw.

I will try reproducing the issue using the steps you mentioned in your previous post. I might add some assertions so that Initialize, Update, and Draw are called in their proper places and only once. I am also looking into potentially needing only the Slab.Initialize call in the project and have Slab internally manage the Update and Draw calls.

[flamendless]

Hi, I've finally found the solution after reading what you've said. I did this:

--debugging system
local slab_init = false

--init() --called every scene load
if not slab_init then Slab.Initialize slab_init = true end

So it's sure that it is only initialized once.

---

love.update -> Your Game Update -> Slab Update -> Slab Function Calls

in the example, the Slab.Update is called first though.

---

Last question: Should Slab widgets be done in update or in draw?

[coding-jackalope]

Hi @flamendless, good to hear you have found a solution.

Slab.Update should be called before any other Slab functions. The Slab.Update primes the internal state for Slab function calls.

Slab widgets ideally should be done in the update loop, but Slab widgets do not make love.graphics.* function calls until Slab.Draw is called, so theoretically, Slab widgets can be done anywhere before Slab.Draw.