I found that you can have multiple setup and draw functions in a project. In order to run the specific setup and draw functions, you just drag the tab ,where the setup and draw function are located, to the rightmost tab.
For example.
Main, Test1, Test2,Test3
all tabs have their own setup and draw functions.
To run the setup and draw in main tab, you have to move the Main tab to the rightmost as follows:
Test1, Test2, Test3, Main
To run the setup and draw in Test2 tab, you have to move the Test2 tab to the rightmost as follows:
Test1, Test3, Main,Test2
This is the way that I can create only one project to test many coding in Codea.
In fact, I found it when I copied and pasted the code from @gunnar_z’s the Coroutines Examples which have three samples. When I create a new one, it runs with different output. Thus, I tried to change the order of the tabs and it works.
Must admit I think this is a bug and I personally don’t like it - another feature you have to look out for to avoid clashes. In fact it begs the question about the whole structure. We may be better setting the system up to provide a new project up with a main.lua (containing the setup(), draw() and touch() functions), then subsequently added Class modules would not have any modules present enabling the user to add what is needed. That would mean that all draw operations occur in main, but using subroutines in other classes to do the hard work for it. Perhaps I’m missing something.
Seems like, if you want to select start up options, you build them into the Setup() function of the main.lua application.
My main issue is that whenever you add a new Class, it automatically is placed to the left - which I shuffle later to retain the main class in that position to open when you open the project.
Any other views.
Also I note 1.4 has been defined - does it (pleading) introduce the proposed project file systems that have been investigated ???
The reason it works is not due to a bug — it’s because the tabs are loaded into Lua from left to right. This causes the functions in the right-most tabs to overwrite the functions in the previous tabs. It’s just how Lua behaves with regards to multiple function definitions.
Doing this properly is fairly simple. You can create “Scene” classes that each manage and render a particular scene. (The physics demo does this.)
1.4 is heavily focused on letting users get custom assets into and out of Codea. So once we have that in place we’ll start looking at more arbitrary data. (That said it should include new ways to get arbitrary data in, too.)
Lua defines functions in order; the only way this causes a conflict is if you have multiple “draw()” functions, for example. If you don’t want the order to change behavior - don’t define draw() multiple times.
Having said that - this seems like an excellent quirk to make certain types of activity (debugging!) much easier. Just define your debugging versions of stuff, and drag them right or left to “turn them on or off”.