Runtime:addEventListener("system", onSystemEvent)

Solar2D Win32 Desktop
#1

Using daily build 3018 I am getting a runtime error reported in the log for: -

Runtime:addEventListener(“system”, onSystemEvent)

when running a compiled app in Windows.  However the app still runs and nothing is reported in the App.  Is this correct?

21:09:05.904  ERROR: Runtime error

21:09:05.904  ?:0: attempt to index global ‘system’ (a nil value)

21:09:05.904  stack traceback:

21:09:05.904   ?: in main chunk

When using the latest daily build 3114 the compiled app will not longer open in Windows…  Just get the above error…

Can you confirm if I should be using this event with some platform specific flags or is it just an oversight with regards failing the app in Windows if this event is being used…?

#2

Found the issue, but not clear why it is an issue in Windows… Not on any other platform…  I have a uber Config file that loads a text file to define the screen layout.  Seems to work on all other platforms.  Since build 3109 this is now stopping the app running.  The system global error, must be associated with the system.DocumentsDirectory…

 local configData local path = system.pathForFile( "config.txt", system.DocumentsDirectory ) local file = io.open( path, "r" ) local s local function split(pString, pPattern) local Table = {} -- NOTE: use {n = 0} in Lua-5.0 local fpat = "(.-)" .. pPattern local last\_end = 1 local s, e, cap = pString:find(fpat, 1) while s do if s ~= 1 or cap ~= "" then table.insert(Table,cap) end last\_end = e+1 s, e, cap = pString:find(fpat, last\_end) end if last\_end \<= #pString then cap = pString:sub(last\_end) table.insert(Table, cap) end return Table end local scaleMode if file then for line in file:lines() do configData = split(line,";") s = split(configData[1],":") scaleMode = s[2] end io.close( file ) file = nil else scaleMode = "letterbox" end application = { content = { width = 768, height = 1024, scale = scaleMode, fps = 30, antialias = true, xAlign = "center", yAlign = "center" }, }
#3

Sorry, the code still works!  So, not sure why the runtime error is generated.  All I know if I use Build 3109 or above the app will not start following that RunTime error.  3018 the app will run.

#4

Hi @matt405,

Can you explain what the goal of doing this kind of file-related work in “config.lua” is for, and how differing the scale mode is used in your overall UI/design? I’ve never ever seen this done before, and I honestly cannot recommend that you continue doing so. It might “work” (or it previously did) but it seems like a vast more amount of complication, so I’m naturally wondering why it must be done. I find that “letterbox” solves 85% of my app needs, “zoomEven” fills in perhaps 5% more, and “adaptive” fills out the remaining 10% for biz/utility style apps. To each his own, obviously, but I would never consider deviating from one scale method personally.

Best regards,

Brent

#5

Desktop builds are different beasts than mobile builds. I do not believe that config.lua can access our API calls on Desktop apps and this is not something we will add support for because of how desktop builds works.  

Rob

#6

This work stemmed from the issue we have with bleeding of images and display objects when the screen was in stretched mode.  We have a couple of thousand users of our business app, all using the app on different platforms - so we have some on HD displays, but we also have some using it on very small lap-tops etc.

The app is designed for IOS and Ipads, but with Corona you can compile into all of these platforms we provide in Windows, Android, MAC and IOS.

We released an update a couple of months ago to eliminate the bleeding issue so that the app only worked in letterbox mode.  But then we had a backlash from some users on smaller screens, especially smaller Windows screens and Android devices, where the visible screen was a lot smaller with white space bands down the side.  They requested that the screen be stretched again!

So we had say 200 users who wanted it stretched, and the rest were happy with the proportional zooming.

To provide our users what they wanted, we built into the app is a screen to set-up your device.  One of the options in this screen is to define how you want the screen to size when expanded.  Do you want it to stretch to fill the screen or expand in a controlled way.

Don’t forget the Windows build supports maximisation of the screen so for some user who are on very wide, but narrow screens this feature is useful.

When the user saves the screen I simple write the config.txt file and advise them to restart the app.  When they restart the app the screen now behaves in the new format.

As I say, this feature is also useful in Android as some of these devices have odd shape screens…

I got the idea to do this from one of your blog posts !! https://coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/ - but that is no longer there… :frowning:

#7

Rob - thanks for your comments.

I suppose what I am looking for is consistency if possible.  This functionality works great on IOS, Android and the Simulator.  It worked up until a week ago on Windows builds.  Now in the latest build it stops the App from running.

Would be useful to really understand why if possible as for us it is an important feature for our users…

Logically I cant see why accessing API calls in the Config.lua would be an issue…

#8

Hi @matt405,

As some know (because I’ve been vocal on the matter over a long time), I personally do not support the method advertised in that “ultimate config” blog post (the post was not mine, nor my idea). I won’t go into detail again on why, but I never condoned it from the beginning and I still don’t. Now, some people like it and, again, they’re free to utilize it… but I don’t see any possible situation (even yours) where a set scale like “adaptive” couldn’t accomplish everything that all of your users desire, with just a little clever coding on your part.

For example, you could compare the content area W/H that “adaptive” comes up with to predict if they’re on a phone or a tablet, and make minor adjustments to your UI. Or you could use “system.getInfo()” details to figure out what type of device they’re probably running on, and adjust your UI based on that. There are probably other ways I’m not thinking of too.

As for making API calls in “config.lua”, I maintain that the intention of that file is for configuration purposes only. Some may disagree, but even then, there’s a big difference between making some “display.*” calls versus doing things like file I/O… remember that chews up precious milliseconds right as the app launches as it tries to access the disk, then it has to parse the file using “string.*” calls and whatever else. I don’t feel comfortable about doing any of that within that file, as “main.lua” may even attempt to execute before that file I/O is complete (this is not something I’m fully in tune with however; it’s a core engineering thing).

Best regards,

Brent

#9

Hmmm…  I don’t think I do agree I am afraid.

Of course there are trade offs.  There always area.  Like my users who decided to have the screen stretched, even though that means that some display objects could potentially bleed into other objects.  I made them aware of the potential issues and they make a choice.  But for them being able to see the screen on tiny devices is more important.

I can see nothing compelling to explain why we can’t save a Corona Config settings in a file.  Certainly the milliseconds on load is zero as we all show splash screens after that anyway.  

And when did not loading an app configuration from a file become so radical??  That is bread and butter business app surely…

Anyway, I think we have to be prepared for users to use our software in different ways and celebrate it.  Sure, provide caveats if there could be risks, but we should never shut it down to try and get them to conform to “our” way of working.  

Looks like we will have to provide a different solution to our problem if we are going to use the new builds… :frowning:

#10

Honestly, I’ve never seen anybody do file I/O work in the config file, in all of my years with Corona. So it does seem like a radical concept which nobody else has attempted. Also, don’t you get customer complaints about restarting the app to “reconfigure”? Meaning they have to force-quit the app entirely?

Biz apps really benefit from adaptive scaling. I wouldn’t use anything else for a biz/utility app personally.

#11

The problem is that config.lua is not a “normal” Lua file as far as Corona is concerned. It’s a special file and was never designed to do any real work. Yes, it is a Lua file, but its main purpose is to provide a simple Lua table with configuration settings and is read before Corona is properly initialized. Corona uses config.lua to do just that: Initialize Corona.

The only safe place to start doing real work is in main.lua.

#12

I was describing business apps in general Brent.  Not Corona.  All of the business apps I have ever worked provided some IO file configuration.   I would say that was pretty much standard.  In fact I had to edit the Sublime Text config file only yesterday! :slight_smile:  

The only reason they have to force quit the App is because there is no current way of restarting an App in Windows.

Anyway, I get your passion and I share it.  I love this product.  But the reality for our users of our system, written in Corona, is that this is going to cause a load of hassle… 

#13

@Ingemar_cl - all I want to do is to save the users config.  In the old, old days that was called a INI file.  I don’t want to muck around with the display or do anything to crazy - yep that has to be in the MAIN and onwards.  But if the user wants the config a different way and has previously saved those choices, why cant the Config just read those settings in?  Why must it be hard coded??  

Hey, it works and it has always worked - my issue is that since 3108 is going to stop working… :frowning:

Functionality has been removed and I am never a fan of that unless someone has a bullet proof reason for it…

#14

I get what you mean about the “init” or “INI file,” conceptually, but “config.lua” effectively is that file and it works in that basic manner (as a file which configures the project). What you’re doing is loading another file from the “INI file” to modify the “INI file” itself, which is where things go awry.

Basically, you’ve found a loophole in the system which was never really intended, and it’s not basic functionality we support. This is the nature of things: as one example, you simply can’t perform certain actions like network calls at exact times when the app is closing/quitting… well you “can” but likely it will cause all sorts of issues/problems. There are essential limitations which should be obeyed to avoid issues like the one you’re having.

Best regards,

Brent

#15

OK - we will try and find another way.  If you could put onto your very long list some kind of dynamic config.lua modification, mainly for desktop builds I would appreciate it.

#16

Hi @matt405, are you saying desktop builds allowed this in 3107 and earlier? I don’t see anything we changed in 3108 that would impact it. There is a possible change in 3102 that might. Can you confirm that you can do what you’re doing in 3107 but not 3108 on desktop builds?

Thanks

Rob

#17

No, sorry Rob, 3108 is working OK.   I tried 3114, 3113 and then 3110.  None of which like my code…  So it must be 3109 or 3110…

I need to get my head around the alternative options as it will be an issue going forward.  We have 4 apps now built through Corona.  One App has 263 LUA files, 673 images.  It being a business app it uses the widgets and overlays extensively.  

To add to that it then needs to work on all 4 platforms with various size screens.  Not easy to get a once size fits all solution (no pun intended!).  

#18

Can you try 3109? It will help a lot when I take this to Engineering.

Rob

#19

So, downloaded 3109 and that was the release it all stopped working for me…  Error is this now: -

22:04:45.580  ERROR: Runtime error

22:04:45.580  ?:0: attempt to index global ‘system’ (a nil value)

22:04:45.580  stack traceback:

22:04:45.580   ?: in main chunk

22:04:48.789  Application closed with exit code: -1073741819

:frowning: - back to 3108 for now…

#20

Thank’s I’ll see what I can find out.