A number of others have asked this question, but it's never been answered. The problem seems trivial and yet it hasn't been addressed in Apple's documentation or elsewhere.
I'm presenting my UIActionSheet instance using the showInView method:
UIActionSheet *myActionSheet = [[UIActionSheet alloc] initWithTitle:#"Test" delegate:self cancelButtonTitle:#"Cancel" destructiveButtonTitle:#"Destroy" otherButtonTitles:#"One", #"Two", nil];
[myActionSheet showInView:self.view];
The UIActionSheet is rendered in the center in whichever orientation it is launched, but when I rotate the iPad, it is seen in the top-right or the bottom-left (depending on whether the orientation changed to Portrait or Landscape).
This behavior is what one would expect if the Autoresizing Masks were set to UIViewAutoresizingFlexibleBottomMargin and UIViewAutoresizingFlexibleRightMargin, which is the default autoresizingMask value for most view elements, so I tried resetting the value by calling the setAutoresizingMask method on the UIActionSheet instance.
[myActionSheet setAutoresizingMask:UIViewAutoresizingNone];
But neither this nor any other value for the Autoresizing Mask achieves any change whatsoever.
Is there any solution to this problem?
I would prefer not resorting to dismissing the UIActionSheet on rotation and re-displaying it - that approach seems unnecessary in principle.
UIActionSheet is a UIView subclass, so you can set the frame of it if you want.
I just tested it and setting the frame has the desired effect.
Related
My app has a multi-pane tutorial-style view that users swipe through to learn about the app. This is implemented very much as described in this tutorial. Having implemented it for both iOS 7 and 8, I'm comparing how they work, and finding issues with the latter — I'm running Xcode 6 GM here.
It seems that the UIPageViewController is rendering the views after the transition is complete. I overrode the delegate methods to see what was going on:
- (void)pageViewController:(UIPageViewController *)pageViewController willTransitionToViewControllers:(NSArray *)pendingViewControllers
{
NSLog(#"Frame size before: %#", NSStringFromCGRect([(UIViewController*)pendingViewControllers[0] view].frame));
}
- (void)pageViewController:(UIPageViewController *)pageViewController didFinishAnimating:(BOOL)finished previousViewControllers:(NSArray *)previousViewControllers transitionCompleted:(BOOL)completed
{
NSLog(#"Frame size after: %#", NSStringFromCGRect([(UIViewController*)previousViewControllers[0] view].frame));
}
And here's a sample output:
Frame size before: {{0, 0}, {600, 600}}
Frame size after: {{0, 0}, {320, 568}}
This manifests like so: swipe to the left to pull in the next view, and note a 32-pt white space at the bottom of the new view. Once the transition is complete, it jerks into its proper layout.
Is this a bug in iOS 8, perhaps? I'm all out of guesses at this point.
I figured out you need to base your constraints on the view and not the layout guide of your view controller. This will ensure your view controller respects the constraints you set prior to the transition in a PageViewController.
you can do this like so:
Remember to uncheck "Constrain to margins"
For anyone having this issue, for me it appeared to be that I was laying out views "relative to margin" (a new feature in iOS 8).
Instead of:
Use:
I've been struggling with this for a few days.
I tried to implement it by instantiating the page ViewController from the storyboard. There was a definite resizing occurring. Checking the frame size in
pageViewController:viewControllerAfterViewController
pageViewController:willTransitionToViewControllers
pageViewController:didFinishAnimating:previousViewControllers
The frame size would always change between the calls to 1 and 3. Sometimes before 2 and sometimes after.
If you're also using storyboards, I was able to resolve the issue by extracting the page UI elements into its own XIB file, setting the constraints in IB and then creating the pages with a call to initWithNibName.
Not a complete answer but it returned me to feeling productive.
Hope it helps.
For me solution was to pin top of the tableView to superview:
Editor -> Pin -> Top Space To SuperView (iOS8)
It is a bug in iOS 8 but I found a workaround:
Add an empty view on top of the statusbar in your Storyboard. The height of the view should be as much as the y-value of your object that is being moved.
[qt 4.8]
To get correct window dimensions including its frame, I do the following (as described e.g. here, see comment from Daniel Hedberg).
mainWindow.move(-50000, -50000);
mainWindow.show();
// do something with the window dimensions
mainWindow.move(0, 0);
mainWindow.show()
This works fine, however, I have a problem with the move(0,0) call: It makes the window always appear at position (0,0), while I would like to have the default behaviour, this is, the application only suggests to the window manager that (0,0) is a good place to position the window, and the WM might decide to shift it if necessary to avoid overlapping. In other words, I would like to switch back to Qt's default behaviour as if there weren't a call to move at all.
How can I do that?
One solution is to store Windows original position and use that. For extra safety (in case screen resolution changes), check that entire window still fits on screen and move and even resize if it does not.
A hacky alternative would be to create and open empty, possibly transparent dummy window of the same size and see where it gets positioned. Then move the original there and close the dummy one. Reading your question carefully, I think this would do what you are after.
I don't know of a Qt way to ask Window Manager to reposition the window, so if you really need that, specify the OS etc details.
Looking into the source code of Qt, I can now partially answer my own question: To convert a call to move into a suggestion for positioning instead of a request, do this:
mainWindow.move(100, 100);
mainWindow.setAttribute(Qt::WA_Moved, false);
mainWindow.show();
I've tested the code under X11 using Qt 4.8.4, and hopefully it works with on other platforms too.
Unfortunately, this doesn't solve the very problem I have, namely to use show to get the (decorated) dimensions of an off-screen window which then gets moved to the screen, calling show again. It seems that the first call to show directly sets platform-specific window manager flags which aren't completely reset and reevaluated in the second call. Actually, I'm going to think that this is a bug in Qt, so I'll report it accordingly.
Having recently switched to autolayout in Xcode 5 (and having watched the developer video from WWDC 13), I'm finding things to work pretty well with the exception of a View-Based NSOutlineView.
Before autolayout, this worked. Everything works fine and is in the right location, but now, specifically when I scroll, some of the new entries (and not all of them) end up in the wrong place, always larger and slightly higher.
The problem goes away once they are redrawn, but I don't understand the mechanic for drawing these NSTableCellViews and when they are created by the Outline View. I mean, it looks like they are created at some point, the program is guessing about the proper constraints, and then fixing them after a redraw.
It would be really nice to post an image to explain this, but can someone explain the life cycle of a view in an NSTableView or NSOutlineView?
I had to grapple with that issue myself and I was able to fix it today. This will happen if you are using any content inside an NSTableCellView that needs to be resized to fit into its cell or any subview of it. I fixed this problem by using an NSImage with the exact same size as a placeholder NSImage I added as subview to the NSTableCellView on IB. This resizing will break the constraints you added to or expect in this view.
I am making an app using Qt (currently 4.8) which displays a literal map from a large number of QGraphicsScene items. I would like to annotate the view with a scale. My requirement for the scale is that it is permanently fixed w.r.t the viewport widget. It needs to be updated whenever the view scale changes (zoom in, etc). There are other possible overlay items as well (compass, etc) so I'd prefer a generic solution.
I have looked at earlier questions around this which suggest:
using the ItemIgnoresTransform
using an overlay pixmap.
I tried IgnoresTransform but that way didn't work right: I couldn't figure out how to fix it in place in (say) the bottom corner of the viewport and was having some difficulty getting the text and lines always displaying in the correct size.
I scrapped that and subclassed QGraphicsView, adding an overlay pixmap by reimplementing the paintEvent (calls original one, then paints the overlay pixmap on top), and an alignment option to indicate where it goes. Coding some pixmap paint code produces a usable scale on the view. Yay! ... but it doesn't work with scrolls - I get "shattered" renderings of the scale all over, or sometimes no scale at all. I think this is because QGraphicsView::scrollViewportBy() uses viewport()->scroll() so I wondered if switching to ViewportSmartUpdate would help, but it doesn't help enough. I'd prefer not to switch to ViewportFullUpdate as that would likely slow the app down too much (there are millions of items in the scene and that would require a full repaint just to move around).
So. Any ideas from here? Would adapting my pixmap code to write to a new mostly-transparent Widget that is overlaid on the viewport be a better way?
Thanks for any help...
Though it may not be the best way of doing this, in the past I've added custom widgets to the window that holds the QGraphicsView / QGraphicsScene, which have the same graphic style as the QGraphicObjects in the scene. When the view is then used to move objects in the scene, or the scene itself, the items on the window remain in the same place.
Hope that helps.
I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.