Tableview Build event required - Called immediately after 'table' has 'painted' onscreen:

Solar2D Advanced Graphics
#21

I just looked at the bug submission and it’s missing a project to reproduce the problem.  You attached a .lua file, but you did not include the config.lua and build.settings or the main.lua.  I tried to grab the code and see myself, but it immediatly errors because there are things in your main.lua that the scene is dependent on.  Please produce a .zip file with all the required assets.   In other words, QA will unzip the folder, open the folder in the simulator and want to see what you’re reporting.  They cannot do that with what you sent and we can’t afford the time to try and reconstruct the missing pieces.

I’m going to respond to the ticket so you will get a new email that you should be able to attach the .zip file too.

Also, can you explain the use case for putting 50 display objects in one row?  Trying to get that many rows on the screen at once?  The screen shot doesn’t look like something you would use a tableView for.

Rob

Rob

#22

Thanks I will look at the email.

Sorry that the case was missing the project. I just sent a TAB.lua  from the corona samples and hope it could be merged. I will recreate and send as requested.

Example of [possible] 50 objects in a row…

This is   copyright ColourMyApps Ltd., but if you take a game which can draw 5 from 50 numbers.

So to draw a graphical history map, one row for each game to see a pattern over time , to see if there is a bias, the easiest way I could see was to map the results into each tableview row, for each game.

So if a game result is 5,18,35,47,50 these are the positions across the row that will have the ‘square’ highlighted. So although only 5 per row each row is ‘marked’ in special ways to show and highlight any close numbers or repeats or directional 'drift’s  over the last few games [bias]. So for every row, the prior rows are looked at to mark ‘trends’ and highlight ‘squares’ as to next likley ‘game’. some will be dark, while others will be lighter. There are games in real life that having 5 from 50, or similar results that will be better understood. What I sent was just a random mix for testing processor bound lock-out of the spinner.

I am looking at speeding this up by just hitting the actual square,from  internal table lookups, instead of scanning/plotting all 50 positions.

Even so there is still some processing before the objects are drawn and this does cause the spinner to be not shown until tableview is built.

Thanks

Alec

#23

I’m not sure how much of a bug this is actually.   Your code snippet has a couple of things and then there is how Corona renders frames. 

You’re spinner is logically behind the tableView.  You’re not going to see the spinner because it’s behind a solid object.  I changed the order to create the tableView first and now I can see the spinner… sort of.

Corona SDK renders things on a frame cycles.  Basically when you do:

for i = 1, 3000

   – do some work

end

All of that work will render on the next frame update.  If you do more work in a frame cycle than the frame rate can support, you get a delayed update.  For the most part, Corona SDK is a single threaded process.  Somethings like audio will run on a different thread, but a given block of Lua code has to complete before the update happens.  If you wrap your for loop into a function called doWork() or some such then call that in a timer.performWithDelay(20, doWork) you will see the spinner, but it doesn’t spin once doWork() starts working.  By the time your 3000 rows are created you have already cancelled the spinner before the next frame update happens.

This might be a good use for a CoRoutine, Lua’s equiv. to threads.  See this tutorial:

https://coronalabs.com/blog/2015/02/10/tutorial-using-coroutines-in-corona/

Rob

#24

Understood. I forgot the runspinner:toFront() in my test run. So also now, sortoff see it, at the end.

Do you have any thoughts on being able to highlight the spinner more for the dark or gawdy scene[if/when  I get it working ok]?

About a year ago I came across this problem and tried to write a ‘dispatcher’ via timer.performWithDelay to build the table, but dismissed it then due to getting too complex from the then limited knowledge of Corona. I will go back and look  and compare using coroutines [or maybe re-write the offending routines]. Thanks for the link.

Thanks

Alec

#25

https://coronalabs.com/blog/2015/02/10/tutorial-using-coroutines-in-corona/

http://www.jucs.org/jucs_10_7/coroutines_in_lua/de_Moura_A_L.html#conw63

reminiscing…

Very very interesting. At around that 1965/6 I was working on multi-tasking language called PL/1

http://en.wikipedia.org/wiki/PL/I

Later working on CNC machines and CAD.

http://en.wikipedia.org/wiki/History_of_numerical_control

Writing  dispatchers at machine assembler code level called process control [CNC is  now moved onto robotics I guess] that is exactly as mentioned under Coroutines.

I have never heard it called that before [IBMers always had their own language] hence not noticing the referenced articles.

The technique could be very useful, I suspect in mutiple image moving games…

Thanks for that,

Alec

An after thought…

How about using this for co routine style scenes in composer and/or storyboards to allow muliple scenes r_unning…displaying in different screen sections/boxes_

#26

For what it’s worth, my first official programming class was using PL/C and PL/I back in 1980.  Though by the time I got there I had taught myself BASIC and DEC TOPS-10 assembler.  Dabbled in SAIL, ALGOL then it was IBM 370 assembler and then on to Pascal and FOTRAN.  Or something like that.  Then I learned C and basically purged every other language out of my head.

Rob

#27

I thought I could see hints of that thinking here in Corona.

Without boaring the readers, too much,  I went onto windows and Visual Basic [VBA} lecturing and that kept me busy for 10 years. So now just trying all that out here in Corona…

nuf said!