I've spend the past three days trying to figure out the iOS-6 autorotation mess, and have not arrived at a solution.
It's relatively straight-forward to have an app where all views rotate, or where rotation is completely disabled. And (conveniently for our needs) if you use a MPMoviePlayerViewController it will autorotate even if the app has autorotation disabled.
But having conditional autorotation, where some views are allowed to rotate and others are not, is elusive. I can achieve conditional autorotation (by having the root view controller "consult" the top view controller to determine what rotation it permits), but when the rotated view is exited it leaves the prior view rotated (when previously it had not been). This is not acceptable.
Has anyone cracked this nut?
(Like I told my boss, if you want a wider view you should just put wider paper in the printer.)
Further problem: Having gotten the basic conditional rotation to work (see comments below), I find that it hoses some screens in the "right wrong" circumstances. On this non-rotatable screen I press "Intro" to go to a rotatable one.
On the rotatable screen I rotate it, then return from it with it rotated. When I get back I have this screen:
The XIB file is pretty vanilla:
The errant piece appears to be the "Image View -- img_hea..." element which for some reason gets "amplified" vertically about 4x. There is no logic moving/resizing elements in the view (other than the standard UITableView stuff), and no reference at all to the problem UIImageView.
With an NSLog placed in viewWillAppear I see that the UIImageView is dimensioned 320x44 initially but 320x160 on return from the rotated screen.
This looks like an out-and-out Apple bug.
More: If I make the problem screen rotatable and rotate it right/left (back to portrait) the image is screwed up. I'm guessing that iOS "returns" to the screen before rotating back, and that's why it gets mucked up. Interestingly, in the rotated view the UIImageView is not showing up at all, with the Y dimension coming out zero in the NSLog.
Also, now that I notice it, the label that had been superimposed over the problem image is gone altogether in both rotated and post-rotation views.
OK: Turned off "Autoresize Subviews" for the overall UIVIew, and that makes things work correctly. This is the second time I've found the "Autoresize Subviews" XIB attribute causes flaky behavior.
Related
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I have 2 views. A MapKitView and a UILabel. Auto Layout is on.
I want the MKView to take up the whole screen (this seems to work fine) and the UILabel to remain the auto distance from the bottom of the screen but centered horizontally. The UILabel contents are changed programatically and afterwards I am calling sizeToFit.
After calling sizeToFit on the UILabel then it is no longer centered - the width seems to be adjusted only from the right hand side (trailing edge) keeping the left hand side in a constant position.
My understanding is that I should be able to achieve what I want only by setting the right constraints in IB?
The constraints I have applied to the label are:
Height Equals: 32
Width Equals: 166
Bottom Space to: Superview Equals: Default
Align Center X to: Map View
Only the last one, "Align Center X" is a user constraint - the rest being IB supplied.
I have tried a number of things, though none with much understanding (presumably my problem!).
I have called setTranslatesAutoresizingMaskIntoConstraints: NO on the label.
I have set the label's autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin. I have tried setting preferredMaxLayoutWidth to random values. Calling needsUpdateConstraints on the label. I tried putting the call to sizeToFit in viewDidLayoutSubviews.
I have come to the conclusion I need a little more understanding how I should be approaching this. Is sizeToFit not the thing to be calling when Auto Layout is on? Do I need to prod Auto Layout in some way after calling sizeToFit? I notice that rotating the simulator seems to center the label so prodding sounds a possibility?
I have re-read the Apple Auto Layout guide but I'm afraid I'm still not sure what I am doing wrong and the debugging tips suggested (visualizeConstraints etc) don't seem to work on iOS.
Thanks for any clue you can spare.
My idea about having to prod appears to be correct. After calling sizeToFit I needed to call [label.superview setNeedsLayout]. Whilst this works I'm not really sure why I need to do this manually rather than the label marking the layout as dirty when it's size changes.
I know it sounds a bit odd but perhaps someone has experienced the same too.
If I have a UIToolbar placed at the bottom of a Retina 4 sized xib (548 size) it does not work in the simulator (buttons show no reaction). However if I place it a bit higher (not sure where the threshold is) they work again. ???
My problematic xib looks like this:
As mentioned elsewhere (e.g. iPhone 5 (4") bottom toolbar not responding ) the problem is that even though your view is the full height, the underlying UIWindow isn't, and the underlying UIWindow is involved in your view getting touch events.
If you have a file name something like "MainWindow.xib" in your project:
Open it in Interface Builder.
Select "Window" from the list of objects on the left side.
In the Attributes Inspector pane, click the "Full Screen at Launch" checkbox.
UI elements at the bottom of the screen should now work.
I found the problem being the UIWindow. (perhaps it is only a problem with older projects) As long as the window object it set to the 480 size actions falling out of its size (which can happen on Retina 4) are not recognized.
In my WPF app I have a control representing a pack of 20 cards (each about 150x80 px) that fan out in an arc, so they're all slightly overlapping in the centre of the arc. When the control is added there's an animation to fan them out.
After that, the fan/control can be moved around, and when the user hovers over a card it expands and then goes back to normal size when they move off it.
This all works fine, but has a noticeable effect on performance- everything is very jerky, presumably because when other things move all the overlapping stuff and transforms in the control are being constantly recalculated/redrawn.
Any suggestions for how I can improve performance while still keeping individual cards in the fan responsive?
To find the source of the slowdown you need to profile.
Try to find out whether or not WPF is switching back to software rendering or not.
After that try to run on a different computer with other (better) hardware/graphics card.
If it doesn't get any better there might be errors in your app.
I have a WPF application with many tabs..
in one tab.. i make a verycomplex vector drawing consisting of thousands of drawing visuals.. (this represents a machine and all elements need to be interactable..)
It takes 3/4 seconds for drawing this for the first time..After the first draw it should be done..
The problem is if i switch to another tab and comeback, it takes atlease 2,3 seconds to show the tabpage with drawing again.. Since there is no redraw, why should it take so much time..?
If the component is not going to change, you could call Freeze() on it to mark it as done. Without trying it out I don't know if that would help, but you could give it a shot.
Not all objects are Freezable. Check out the MSDN documentation for more info:
http://msdn.microsoft.com/en-us/library/ms750509.aspx
Another thing you could try would be rendering the vector art to a bitmap, and displaying that. Maybe it makes you feel icky to lose the vector precision, but if you know it's not going to change and it will look the same, what's the harm? (If you support printing or something that will require a hi-res version, you could always switch back for that operation.) For info on how to convert a UIElement to a bitmap, check out:
http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.rendertargetbitmap.aspx
Another possible solution: You don't really explain what kind of interaction you are doing with the elements, but if all you want to do is zoom and pan, a RenderTransform may be good enough (which is more efficient than a LayoutTransform and/or moving all the elements individually). I haven't played around with combining Freeze() and a RenderTransform, but you may be able to get the desired zooming while reducing the amount of layout WPF has to do.