Flex 4: Scrolling a Spark Form to focussed element programatically? - apache-flex

I found this example http://blog.flexexamples.com/2009/11/02/auto-scrolling-the-contents-of-a-vgroup-container-in-flex-4/ which works great but only if you have the focussable elements in a VGroup.
However I have a Form inside the VGroup which means that the focussable elements are in FormItems of the Form. The Form can't be added directly into the Scroller and doesn't have a layout property.
I could use form.getElementIndex(formItem) and then do some math using the formItem y position but that's very ugly. Anyone have an idea how to get this working in a clean way like the above example?

Woot woot! I just found Scroller.ensureElementIsVisible()! Nevermind! :D

Related

Create Profile Dropdown Menu in Polymer with Triangular top

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.

Nativescript: How to overlay one StackLayout over another StackLayout

I have a search suggestion component that is displayed under a TextField. whenever text is entered into the TextField the search suggestion component displays a list of possible matches based on the current entered text... I have more content under the TextField that gets pushed to the bottom whenever the Search suggestion gets populated with results. Is there any way to overlay the search suggestions over the content underneath it instead of pushing the content down? in HTML/css I would apply the position absolute and z-index css properties to the search suggestion component but this doesn't seem to be the case in Nativescript. I see that Nativescript does support the z-index css property but just applying that doesn't seem to do anything. It doesn't look like Nativescript supports the position property... Any idea how I can make this work/what i'm missing?
You have a couple quick options. One is to use a grid as mentioned in the comments. Set the views on the same row/col. This is the same as stacking views on the z axis. Or an absolute layout and use the same positioning of the views within that layout.

How to remove padding created by ResponsiveGridLayout control in OpenUI5 (SAPUI5)?

I am creating a form using OpenUI5 and I noticed that when I am using the ResponsiveGridLayout layout, the form gets some padding (blue area around the input fields). Please see result here:
http://plnkr.co/edit/G4NrKPMGdN4DACXZgZOg?p=preview
If I am using the GridLayout layout, the padding is as expected:
http://plnkr.co/edit/Yp6Ul7gLDf0t88vMWrWD?p=preview
Any idea how I can get a form with very a small padding (like in GridLayout example), but in the same time I want to be able to use the 12-column grid system so I can set the size on my input fields?
Ideally, the views need to be XML and to use OpenUI5 classes/controls if possible.
You could just swap the responsible style classes using .addStyleClass() and .removeStyleClass().
Not sure if it works, but thats the easiest possible fix I can think of that might be worth a try.

GWT - PopupPanel, change layout when flipped

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.

Dojo GFX widgets displaying float-like behaviour instead of correct positioning

I'm using Dojo GFX to do some simple drawing, but having a problem with IE 7/8 (switching browsers is not an option).
If I create a div, set up a surface and draw some rects, they draw correctly relative to the div, so far so good.
However, what I want to do is create a widget, something with an embedded 'surface' that draws based on some widget-specific data. As such, I have a widget that contains a div, and I draw into this div. When I do that, the rects I create behave as if they are responding to a float:right, appearing in order they are created and ignoring the 'x' parameter.
I assume that this behaviour is something to do with CSS, but I haven't got to the bottom of it yet. Any ideas or solutions gratefully appreciated!
Updates:
I've disabled all stylesheets and I am not using style attributes. No difference to the behaviour.
I've inspected the markup that gets generated using IE8 dev tools. Apart from the different location of the containing div, the only difference I can see is that the v:roundrect elements have no child elements when created against the widget div, but they do have empty elements like stroke when created against the div referenced by ID.
Reading back through the docs, a difference I can see that might be responsible is that the postCreate method where I am doing my drawing is manipulating a div that has not been added to the dom yet, whereas drawing on a hardcoded div is done when it does exist. Maybe the difference in rendering is something to do with this? Is there a specific lifecycle function which is appropriate to draw in for widgets?
It seems that if you are going to use Dojo GFX and draw on DOM elements that are created as part of a widget in IE7/8, you must actually do the drawing in an override of the startup() method.
Drawing in the postCreate() method causes incorrect rendering resembling a float: left.

Resources