SO I have a UITableView which contains a UITableViewCell and tableView.header is set to a Parallax Header. The UITableViewCell has certain UIViews which are set as negative constraints from Top and are shown perfectly on iOS-12 whereas when observed on iOS-13 the UIViews showing over Parallax Header are clipped. I have tried all possible solutions but unfortunately it still shows the same. My App is opting out of SwiftUI and still running the old code. I have even tried to change the zIndex of the child UIView but still the same. Here are some snapshots and some code:
override func awakeFromNib() {
super.awakeFromNib()
// Initialization code
self.PriceView.layer.zPosition = 1
self.PriceView.bringSubviewToFront(self.contentView)
self.PriceView.setNeedsDisplay()
}
This code is functional for iOS-12 but not iOS-13.
UPDATE:
Apple's changelog/documentation for iOS-13 suggests:
The UITableViewCell class’s contentView property is always laid out
edge-to-edge with adjacent accessories, both on the leading and the
trailing side. This streamlines the layout code so developers who want
the correct default offset no longer have to align their content with
the content view border or the layout margin depending on whether
there is an accessory on the trailing side or not. You should now
always lay out their code on the layout margins of the cell’s content
view to get the default system insets. These insets will be adjusted
automatically based on the accessories visible in the cell to match
the system’s default spacing. (48214114)
This is a bit unclear to me and if someone can help me out here.
Here are the snapshots as to how it is showing in iOS-12 which is required and how it is showing in iOS-13 respectively:
And here observe for iOS-13:
Here is also the Constraint Layout of my UITableViewCell's PriceView:
I need both to be consistent on both OSes. THANK YOU SO MUCH FOR THIS HELP!
Wohoo! I finally figured it out. So before as default it was working on iOS-12 but after iOS-13 and UITableViewCell changes as described in the question, it stopped working. Here is what I did:
Firstly, in the Size Inspector, the ContentView of UITableViewCell was set to Safe Area Layout Guide which I turned off and turned on Safe Area Relative Margins, similarly I did the same for the child, as in the PriceView.
Secondly, in the Attributes Inspector, the ContentView's and UITableViewCell's both had their Autoresize Subviews property turned on, I simply turned it off
And voila! It works. Hope anyone who might have these UITableViewCell issues, please note that now its all relative 😉
Actually, what worked for me was unchecking "clip to bounds" from the attribute inspector for the content view
Related
I am trying to create a profile menu for my polymer website, something on the lines of github.com
If you notice,there is a triangular tip at the top of the menu.I am trying to create a similar triangle at the top of paper-listbox.
The problem I am facing is that the triangle seems to hide as soon as it gets out of the boundaries of paper-listbox.
I have create a jsbin to demonstrate my problem: http://jsbin.com/samaloqowu/1/edit?html,console,output
If you change the top property of the triangle (say -16px), it hides when it gets out of the listbox region. Please help me solve this CSS issue.
Short answer : No you can't.
Explanation : Because the dropdown content get encapsulated in a slotted element that gets styled inside the shadowRoot of the custom element you try to modify the behavior. And the paper-menu-button doesn't actually gives you a way to directly customize the slotted.
But there is a trick ! You can access the slotted through classic javascript. Just alter your connectedCallback function and add this line :
...
connectedCallback() {
super.connectedCallback();
this.$.profileMenu.$.dropdown.querySelector('.dropdown-content').style.overflow = 'visible';
...
}
...
This should do the trick, I agree this looks totally awful and trying to force and change the initial behavior of an element is not really recommended but well it seems to work, just make some tests when the element gets in a new context to see if anything breaks.
UPDATE (22/09/2017) :
Thinking of that again, I think this is a terrible idea to change this overflow to visible, I guess the polymer team has set the overflow to auto because if the list get long and you force the height of the element, the list will flow and be visible which is not really a dropdown anymore, but more like a full list display and that will mess with the general design purpose of your app. IMO when you start trying to mess with the inner properties of a custom element it means this element doesn't quench your requirement, and that it's time to make your own, especially when you try to modify the design of a custom element that has a design already implemented.
I have this problem where the scroll bar's thumb is too small when I apply a skin programmatically. There's no problem when I apply it in the CSS.
main.css:
.myscrolls {
thumbUpSkin: Embed(source="thumb-default.png",
scaleGridLeft="7", scaleGridTop="5", scaleGridRight="8", scaleGridBottom="7");
The above looks fine, but if I try to change the thumb programmatically in the ActionScript later, the thumb is too small, which causes enormous margins between the thumb and the ends of the scroll bar.
ScrollbarColour.as:
[Embed(source="thumb-non-default.png",
scaleGridLeft="7", scaleGridTop="5", scaleGridRight="8", scaleGridBottom="7")]const cThumbNonDefault:Class;
The problem is most likely related to this warning that I get about the above line:
ScrollbarColour_cThumbNonDefault does not extend the 'DefineSprite' asset base class 'flash.display.Sprite'
But if I take away those scaleGrid* members from the ActionScript, the warning goes away.
I used the Flex 3.5 SDK.
However, I made all those Embeds on the stack. If I made them (static) members of ScrollbarColour, I was able to get those attributes to work. I really don't get this language.
I'm creating a context menu for certain elements using a PopupPanel; the menu itself is going to be fairly large and complex. What I'm looking to do is to have a list of buttons, plus an image and some text, related to the element clicked.
My problem is that I'd like the buttons to always display directly under the clicked element, because that's convenient for the user; the issue is that when PopupPanel is near the edges of the screen, it automatically changes position to be fully visible, not aligning its left side to the element as usual. I like this behavior, but it moves the position of the buttons away.
So what I'd like to happen is: normally the buttons are on the left of the panel, the other stuff is to the right. When the panel is close to the right of the screen, I'd like the buttons to instead be on the right (and thus under the clicked element) and the other stuff on the left.
Is there a clever way to do this, either in GWT or better yet, using only CSS? PopupPanel itself doesn't seem to tell you when it's going to get flipped, sadly. The only solution I currently have is to manually check the position and width of the popup before showing it and adjust accordingly, but I'm hoping there's a better solution.
Here is what I suggest (based on my own implementation of a similar use case):
Have the position callback implementation accept references (in constructor) on:
PopupPanel element
element on which user right cliked
the content you put in the PopupPanel
Replicate (I know this not DRY but implementation is package private) the code from default position callback
When opening to the right invoke a method that changes the layout of your content (CSS based or otherwise)
I hope it helps. If you find something better let me know.
Interface Builder in XCode 4.5 respects the intrinsicContentSize for some views, e.g. NSButton, but I can't convince it to respect it on my own custom subviews. This causes IB to add extra constraints trying to force the layout drawn in IB, which then causes the intrinsic sizes to not be used when the program is run.
For example, consider a button centered in a window, and a custom view centered in a window…
You can see that the custom view gets four constraints, presumably because IB doesn't know the view's intrinsicContentSize. You can change which extra constraints are added, e.g. you can force it to be width and height instead, but you can't delete them.
I'm coping with this now by searching and deleting the extra constraints in my awakeFromNib, but there must be a better way to do this.
Set a placeholder intrinsic content size — a "guess," if you will — in Interface Builder.
Select your custom view.
Show the size inspector (⌘Shift5).
Change the "Intrinsic Size" drop-down from "Default (System Defined)" to "Placeholder."
Enter reasonable guesses at your view's runtime width and height.
These constraints are removed at compile-time, meaning they will have no effect on your running app, and the layout engine will add constraints as appropriate at runtime to respect your view's intrinsicContentSize.
How to actually do this, 2019
import UIKit
#IBDesignable class TagPerson: ShadowRoundedImageView {
override var intrinsicContentSize: CGSize {
var s = super.intrinsicContentSize
s.height = 40
s.width = 40
return s
}
override func prepareForInterfaceBuilder() {
invalidateIntrinsicContentSize()
}
}
However, there is a problem. Xcode is buggy. You can sometimes reset it by:
The above will of course work flawlessly at runtime. But it randomly fails to work in interface builder (even with 11+).
To make it cycle, try
The usual 'Refresh all views'
Attach and delete a pointless constraint to one of your intrinsic size views. (I've noticed if you have a number of them, doing this to one is usually enough to make Xcode cycle, then they all work.)
And finally:
Xcode has an "intrinsic size placeholder" feature.
Select one or more of your intrinsic-size elements. Toggle the bizarre placeholder thing back and fore a few times. Often that makes it cycle and the view will then work correctly.
At worst, restarting Xcode with the usual clean-everything will, sometimes, get it working.
Ok, the point here is to make Xcode use the intrinsicContentSize of your custom view in IB.
This can be achieved by adding a placeholder view inside your custom view in IB with a fixed width and height (you can center it horizontally and vertically as well)
Then select your custom view and tap "Size To Fit Content" form the Edit Menu in IB.
At this point all extra size defining constraints will be deletable leaving only positioning ones.
That way IB will size your custom view to fit the placeholder view and and Autolayout would depend on your view's override of - (CGSize)intrinsicContentSize in run time to determine your custom view's size.
Last step is to delete the placeholder view to allow your view to display its content and size correctly:
- (void)viewDidLoad
{
[super viewDidLoad];
[_placeholderView removeFromSuperview];
}
I know this is a hack but hopefully it helps you.
I've noticed that the default behaviour for a DataGrid's vertical scroll bar is to scroll one row at a time. This is all well and good when the rows are all uniform and small (e.g. displaying a single line of text), but gets really ugly as soon as you have rows with variable heights.
I'm curious, is there a way to make DataGrid scrolling "smooth"? For instance, is there a way to have the DataGrid scroll by a set number of pixels, lines of text, etc. rather than scrolling one row at a time?
So far, the only solution I've managed to come up with is to place the DataGrid in a Canvas and have the Canvas do the scrolling instead of the DataGrid. The issue with this approach, though, is that as soon as the Canvas scrolls far enough, the DataGrid headers scroll off-screen. Ideally, I'd like to get the smooth-scrolling nature of the Canvas, but also keep the DataGrid headers visible. Is that possible?
The way that ItemRenderer's work in Flex 3 makes smooth scrolling difficult to achieve. Basically Flex recycles item renderers scrolled off of the top of the list as the display objects used for new data at the bottom of the list. Adobe's implementation of most list components in Flex 3 creates and adds these items as they come on to the screen rather than just off the screen, so they "pop in" and smooth scrolling isn't available. I'm not sure why they couldn't have done it in a similar manner for items +/- one position above or below the current scroll pane, but they didn't, and we're stuck with sticky scrolling by default.
Work-arounds do exist, though the one you've noted (dropping the datagrid into a canvas) negates the display-object saving intention of item renderers and incurs a performance cost. This will be fixed for most list-based Flex components in Flex 4, though it won't be fixed immediately for DataGrid. The DataGrid / AdvancedDataGrid component is maintained by a separate team based in India, last time I heard, and so it tends to be a bit behind the rest of the SDK.
I'd recommend trying something similar to this implementation of a smooth-scrolling list by Alex Harui. I'm not sure exactly how well it'd work for DataGrid or AdvancedDataGrid, but this is the most intuitive technique I can think of for making the list scroll correctly.
Try this... It's still based on Alex's code that was mentioned above. His should still be a great start for removing the snap-to-row behavior. Original source:
http://blogs.adobe.com/aharui/2008/03/smooth_scrolling_list.html
Alex's original some code for smooth vertical scrolling but that was not an issue I had with the DataGrid. It was smooth scrolling horizontally that I needed. I am using the DataGrid in an unorthodox manner for analyzing plain text reports output by our database (great way of providing visual feedback on a document). The code below allows content to go off screen and the user can scroll without that snap-to-column behavior.
You can adapt this to use the same math routines for vertical scrolling and then it will make scrolling possible and ignore the snap to row behavior. In particular switch the usage of the listContent.move method to move the contents vertically and use a inverse of the rounded pixel value you calculate from the vertical scroll bar (as opposed to my using the horizontal).
This method is bit simpler than Alex's method from the link above - a lot less code so try adapting and see how it works.
override protected function scrollHandler(event:Event):void
{
// Override the default scroll behavior to provide smooth horizontal scrolling and not the usual "snap-to-column" behavior
var scrEvt:ScrollEvent = event as ScrollEvent;
if(scrEvt.direction == ScrollEventDirection.HORIZONTAL) {
// Get individual components of a scroll bar for measuring and get a horizontal position to use
var scrDownArrow:DisplayObject = horizontalScrollBar.getChildAt(3);
var sctThumb:DisplayObject = horizontalScrollBar.getChildAt(2);
// I replaced maxHorizontalScrollPosition in Alex's code with "1300" to fix my exact application. In other situations you may finding using some property or different value is more appropriate. Don't rely on my choice.
var hPos:Number = Math.round((sctThumb.y - scrDownArrow.height) / (scrDownArrow.y - sctThumb.height - scrDownArrow.height) * 1300);
// Inverse the position to scroll the content to the left for large reports
listContent.move(hPos * -1, listContent.y);
}
// Go ahead and use the default handler for vertical scrolling
else {
super.scrollHandler(event);
}
}