Glad to hear I’m not alone tbuchler 
And thanks for your report!
Olivier
Hi,
any news from tbuchler bugs Cases?
- Case 42227: Enterprise iPad display.height/display.width reversed
- Case 42228: Enterprise Autorotate includes unsupported orientations
I’ve checked the last Enterprise daily build notes, I didn’t find anything… 
42228 is a total show-stopper for everyone who builds apps that require only landscape orientation.
totally agree : absolutely impossible to publish on a store with 42228.
I hope Corona team will fix it very soon…
This is not documented yet (I’m working on it). Adding following properties to App-Info.plist would solve orientation issue:
\<key\>CoronaViewSupportedInterfaceOrientations\</key\> \<array\> \<string\>UIInterfaceOrientationLandscapeLeft\</string\> \<string\>UIInterfaceOrientationLandscapeRight\</string\> \</array\>
And it is as far as I understand best way to solve the issue.
Update:
I just doublechecked. Both issues #42227 and #42228 are fixed by adding this .plist entry.
Thanks Vlads.
The existing UISupportedInterfaceOrientations and UISupportedInterfaceOrientations~ipad keys should be kept in the plist file?
-Tom
Thanks vlads
display.contentWidth and display.contentHeight
merely reflect the design width and height as specified by the config.lua settings.
i.e. If you specific a width of 320 and a height of 480, and the build.settings file forces the app to ‘portrait’,
application = { content = { width = 320, height = 480, scale = "letterbox" }, }
then this is what you get:
display.contentWidth == 320
display.contentHeight == 480
These values may not necessarily be true pixel sizes. i.e. An on an iPhone 4 with the above config.lua settings, each design pixel is equal to two real pixel.
The design space may not reflect the actual width and height. To get the actual design-space height and width (scaled pixels, not true pixels) use:
display.actualContentWidth and display.actualContentHeight
Read here to learn more about display.*
Note: If you don’t specify a value in config.lua, I think these values are automatic based on the device. Not a good way to go.
Thank you for your answer roaminggamer
I put display.actualContentWidth and display.actualContentHeight but I still have the same issue :
As you can see higher it works for iPhone.
But for iPad, width and height are reversed.
I precise that I use the last config.lua for multidevices :
https://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
--calculate the aspect ratio of the device local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.floor( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.floor( 800 \* aspectRatio ), scale = "letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }
Thanks!
Olivier
I know some will disagree, but I really don’t like the config.lua files that calculate a value for width and height.
I like a fixed (i.e. known) width and height in most cases. This lets me have a known starting point for my design. I find this to be a simple starting point for my own projects and for discussions in the forums.
(I’m not poo-pooing the other configs because their bad, but because I have trouble explaining them succinctly and exploring the problem at hand. i.e. I lack the bandwidth to handle both in a single forum post.)
I use a fixed resolution for all targets or a sub-set, then, when running I handle extra width and height on a case by case basis.
For example, if I go with 640x960 resolution, and the game/app runs on an iPhone5, then I’ll have some extra height to fill if the app is running in portrait.
Anyways, the short answer is, if you’re calculating w/h in config.lua expect numbers all over the place. :wacko:
-Ed
Have you tested this with a bare minimum project to see what you get?
Here is a project I made that includes some of my own code. It sets up some globals (I know eek!) that I use all the time like:
(All values in design space, not true pixel)
- w/h - width and height
- fullw/fullh - full width and height
- centerX, centerY,
- left, right, top, bottom
- unusedWidth, unusedHeight
- orientation
http://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2015/08/config.zip
A test run of the project I’m attaching prints this to the console when run on iPhone 5 simulator:
---------- calcMeasurementSpacing() @ 16 w = 960 h = 640 centerX = 480 centerY = 320 fullw = 1136 fullh = 640 left = -88 right = 1048 top = 0 bottom = 640 orientation = landscape ---------------
or, iPad Air:
---------- calcMeasurementSpacing() w = 960 h = 640 centerX = 480 centerY = 320 fullw = 960 fullh = 720 left = 0 right = 960 top = -40 bottom = 680 orientation = landscape ---------------Using the Moderninzing config.lua you will get different values based on the device, but this is to be expected since you’re using this to avoid letterbox bars and at the same time guaranteeing that 0, 0 is Left, Top and display.contentWidth, display.contentRight is right, bottom. You’re screen will change shape for different devices.
For the iPhone 4s and earlier, that has a 3:2 (1.5:1) aspect ratio, you will get 800 and 1200 for the values (flipped based on orientation). The iPhone 5, 6 and 6 plus are 16:9 (1.777778:1) screens, so you will get 800 x 1420 because the screen is longer. The iPad screens are more square, a 4:3 ratio (1.3333:1) screen. Since the aspect ratio is less that 1.5, we want to keep the 1200 value and make the other dimension bigger. This lets you use the same size graphics on all of the screens. In this case, the 800 becomes 900 (1200 / 1.33333)
So these values are exactly as expected.
This config.lua is based on the idea of anchoring things. If you consider a game like Clash of Clans, the button that lets you expand the chat panel is always on the left side of the screen. My village always draws in the center of the screen. The edit village button is anchored to the right hand side of the screen. On the iPhone 6 the relative distance between those two edge buttons is further apart than on the iPad.
I might draw:
chatBar.x = 50 editVillageButton.x = display.contentWidth - 50 villageGroup.x = display.contentCenterX
If you go with a fixed width and height, which is perfectly valid, then display.contentWidth and display.contentHeight will be your set values and display.actualContentWidth and display.actualContentHeight will be right, bottom… and they will be different since the “actual” ones will effectively be exactly what the calculating config.lua provides in contentWidth and contentHeight.
The catch is 0, 0 does not represent top left. Instead you have to use display.screenOriginX and display.screenOriginY to compute left and top. To use the same example to anchor to the left hand side you now have to compute that position.
chatBar.x = 50 + display.contentOriginX editVillageButton.x = display.actualContentWidth - 50 villageGroup.x = display.contentCenterX
Hope this helps explain this.
Rob
Hi again. I have a tendency to answer questions based on my own biases as a developer, and I would be remiss not to point out the following:
#1 config.lua is a deep topic and there have some genius solutions, posts, and blogs about it here on the site and elsewhere.
#2 I sometimes say (in forums post) that I don’t like another solution (there is that bias), only to remember later that others have put lots of effort into providing solutions (see #1) too.
#3 My solutions may not be the standard solution, or even the most accepted solution. I’m afraid sometimes I see a question and merely come at it from a direction that would solve it for me. Whereas, Rob, Brent, and the others are answering these questions with the following in mind:
a. Is this a standard solution as proscribed by the hard work of staff here on the site.
b. Is this a solution that matches the question asked, versus an interpretation.
c. Will this solution be confusing to the asker, and if so what resources can I point them at.
So, I guess a disclaimer I should give when answering questions is:
" Caveat Interrogaverat : While the following answer works for me, it is based on my bias and the way I work. It may not be a standard solution or suitable for all users."
Thank you Rob, thank you roaminggamer
This helps of course, thanks!
But I’ve still this problem :
my app is Universal and I use Corona Enterprise (Landscape Left, Landscape Right)
display.contentWidth > display.contentHeight on iPhone as expected
display.contentWidth < display.contentHeight on iPad as if on iPad Lanscape Left or Lanscape Right was ignored :wacko:
(see values above)
Thanks again!
Olivier
Hi. We may have been having a semi-deep discussion all this time, when you may have hit an actual bug, so do please tell us the following:
-
What corona release are you using. ex: right now I’m using: 2015.2687
-
Please show your current config.lua contents (including any changes you may have made).
Then, if you have the time:
- Please build the sample project I supplied (using your build process), run it on the iPad that is giving you trouble, and paste the output here. You’ll need to grab it from the xCode device console log.
I want this last bit, because it will help me debug. I can run it on my machine and my iPad, using the same corona release, but do a non-enterprise build. Then, we’ll have this possible matrix:
Works for you || Works for me ==\> Bug in your code. OR issue w/ config.lua (we can investigate this second) Fails for you || Works for me ==\> Possible enterprise bug. OR problem with your setup. Fails for you || Fails for me ==\> General Corona Bug Works for you || Fails for me ==\> UnlikelyThank you for your answer tonygod
Hi roaminggamer, thanks for your help
I’m going to do what you ask this afternoon. (I’m in France, Paris)
I will send my results asap
Best
Olivier
Any luck so far? Just checking in, so you know I’m still here to help. Not pressuring.
Hi roaminggamer,
Corona release : Version 2015.2692 (2015.7.29)
Corona Enterprise 2015.2692
Config.lua
--calculate the aspect ratio of the device local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.floor( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.floor( 800 \* aspectRatio ), scale = "letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, }, }
Sorry, but I don’t understand why you want me to run the sample project you supplied?
You don’t use Enterprise in your sample and I don’t have my bug when I’m without Enterprise…
Thanks
Olivier
Only On Enterprise?
You’re absolutely sure this only shows up in Enterprise? i.e. a copy of your project (minus the Enterprise features you’re using) works fine when built using Pro?
Running My Sample in your Project Setup
The lua files I supplied are still valid to run in your project. If you can afford the time to:
-
Make a backup of your current project (so you don’t lose anything).
-
Replace your main.lua and config.lua with mine.
-
Set your project up to select landscape at the build setting.
-
Run it on your trouble device(s)
-
Grab the results from xCode console
-
Paste results here.
Then, I’ll be better able to help debug.
Interim Experiment
Meanwhile, I’ll run my sample with your config.lua settings and see what I get on my iPad…
With your config, and my example project I get this on my iPad Air (running Corona 2678; Will try 2692 later):
---------- calcMeasurementSpacing() @ 10 w = 1200 h = 900 centerX = 600 centerY = 450 fullw = 1200 fullh = 900 left = 0 right = 1200 top = 0 bottom = 900 orientation = landscape ---------------
I see my numbers are the opposite of your findings. Let me think on this a bit.
This looks very like a enterprise ONLY bug, but I worry there may be something wrong in one of your enterprise files that I’m not thinking of.
** UPDATE: I Just confirmed these results for 2015.2692 on my iPad Air. Now to compare to your results. **