OK, I found an anchor point. 3001 works fine for me. Now I’ll start to roll forward till I experience issues.
3100 not working, i’ll keep testing too
too bad i cannot see what was the previous stable build
3068 also failed and if i am not mistaken, that was the previous build.
something fundamentl seem to have changed.
are you on windows 10 and with latest large update?
I’ve noticed some changes in the windows folder structure and I have a slight feeling it may be messing up new corona installs
i am 100% sure 3068 was working before so im kinda stuck at believing something in the corona install procedure has changed and/or is no longer fully compatible with the new windows 10 folder structure
i’ll try 3059 as well
Well, there is a similar error when using display.* functions in config.lua in desktop applications but seems here is another case.
3059 dont work, this is really weird, im now back installing builds way older than the one I had installed since before the windows 10 update, and which was working fine, with liveBuild and all.
using display function in config.lua is something i do, but only display.pixelHeight and Width
kinda need those
have tried all of this on two different windows 10 machines btw
Well… that’s a problem.
It’s a chicken & egg issue. We need to read your “config.lua” file to determine what the pixel width and height of the window should be, which of course means the display.* Lua APIs can’t be ready for you to use since the pixel width and height you want to read haven’t been determined yet.
Try this advice
https://forums.coronalabs.com/topic/62568-blured-images-in-win32-app/?p=324852
I took a wrong turn here. I managed to roll forward to 3059 and am still in good shape.
I don’t know about your system, but I have to give my antivirus app time to ‘learn that the new install is safe’. I think I rushed my last 3059 build and hosed up the results.
Anyways, continuing to roll forward.
The good news is the failure is probably from some change more recent.
In earlier releases it was a false positive. We printed runtime error to console but app still started. Since 3100 or near it started to prevent desktop app launch and we are working on decent solution at this moment.
Got 3068 working BUT the console complains about the display thing, as you mention above.
I’ve not seen it before since I seldom use the console in the simulator but run main.lua from sublime
I didnt know the api is called after on desktop builds, thx for the link, will chek it out.
Also, thanks a lot for the help with testing RG 
I think this may be caused by something that changed between 2017.3108 and 2017.3109.
- 2017.3108 - Works fine.
- 2017.3109 - My ‘complex’ app fails with the system.* issue @anaqim mentioned.
Summary of steps,
- I first reproduced the error with 3158,
- then I started rolling back till I found a safe and working version. (There were mis-steps in this process thanks to my virus scanner).
- Finally, I started working my way forward trying versions and reading release notes along the way.
It is worth noting I didn’t see anything in the release notes that gave me a hint at the cause. So, thus far I have no idea what the source of this issue is.
Finally, I’ve spent as much time as I can today helping on this so I’ll have to turn back to business now. I hope in the interim @anqim or others can find the actual cause of this issue.
Cheers,
Ed
@Bektur, I have apps that produce the same issue and that do not have display api or any api on the config file, so the issue is more composite, in fact, perhaps not relateted to that display api at all, since even though it was reported, my app with the display api in config still ran and worked fine.
I still suspect the big win 10 update that was pushed out recently.
Not quite sure what else I can do in the matter, do let me know!
@Ed, thanks for your forensics
It would be very helpful if you created a simple demo producing this error. I could have test it on my Win 10 PC
@anaqim - You’re welcome.
@bektur & @anaqim - I agree that a simple test case to help the staff reproduce is the best-case minimum requirement, but be warned this may be one of those rare cases where the test case can’t be simplified.
I say this because I tried to reproduce this will simpler apps and couldn’t, but when I used my biggest and most complex app it just popped out. This doesn’t mean a simpler test case won’t produce it and that is definitely worth pursuing, but I also wonder if sheer size of the project might be part of the issue.
@anaqim - I encourage you to try to make the simplest test case possible for the staff, but if you get stuck after a number of tries and effort please post back. I may be able to give this more time tomorrow.
Hi,
Took Radiance and skinned it to the bone and think i found the issue, or at least how to reproduce it.
Made a light project which shows what happens with latest corona build
Something has changed in how corona accept/handle/deal with config.lua
Tip: Don’t forget to to compress to zip. Not everyone has a 7z compatible app installed. Free not, nobody likes installing extra apps they don’t normally use
Looking now…
Ah, as I suspected in my original answer. You’re accessing system.* in config.lua.
- Did you use it in config.lua?
I wonder if that is officially supported. Like you I do this on occasion, but I don’t remember ever reading it was/is supported.
I used in in the simulator during dev, but not for released apps.
If it is officially supported, then it looks like a genuine and important bug, so good catch.
Ah, bad news. That is not officially supported.
See the Important statement at top of this page:
https://docs.coronalabs.com/guide/basics/configSettings/index.html
Important
Although config.lua is a Lua file, its intention is merely to configure the app in advance of its primary functionality starting in main.lua. You should not make Lua API calls within the config.lua file or perform any actions beyond simply defining the supported tables and key-value pairs for configuration purposes.