I have an mx:Tree, but when the vertical scroll bar appears, it overlaps the content of the tree (odd that the horizontal bar does not). That might be acceptable for the text, but the stripe that I create using the item renderer, for certain items, seems to make it an anathema to the QA guys. How can I keep this from happening?
I have an idea for a workaround: I could make use the item renderer to stop the drawing a little bit short of the right side of the view (not that I can reliably get the width of a scroll bar) but I can't even figure out how wide the displayable part of a tree is--all the properties of a tree seem to be about its entire width, which includes the entire area coverable using the horizontal scroll bar. However, the blue stripe signifying a selected item doesn't seem to have that problem--it stops short of the scroll bar. In any case, when trying to find the displayable region, I don't know if I could handle the added complication of when the horizontal scroll bar is moved. Much better if someone could tell me how to put the veritcal bar outside the displayable tree area (or shrink the displayable area, of course). Thanks.
I'm using the Flex 3.5 SDK
I was able to find the solution when researching horizontal scrollbar issue on list and tree component. The blog to which it links eventually shows a kind of hacky solution (in the readers' comments) that shows how to make sure that none of the drawing is done beyond a certain boundary.
Related
Simple question: is it possible to stack one WKInterfaceLabel on top of another inside a WKInterfaceGroup? I’m dragging like a mad man and I cannot get the blue target line to setting above or below the first label. It’ll sit beside it, to its left or right, but it won’t settle above or below it.
I’m trying to do something inside a table row akin to a master/detail, but I simply can’t figure out if it’s possible.
You can set the layout of the WKInterfaceGroup as Vertical and that will make your labels be one on top of the other.
This happens because WKInterfaceGroup doesn't work like a view, it has a layout flow that automatically arranges the inner WKInterface's as specified by the Layout property that can be horizontal or vertical. You can also tweak the appearance with custom insets.
Flex scroll bars are giving me a really hard time. I want to control exactly which boxes they appear for but after hours of trying random things, my best solution (see below) seems a bit kludgy and unreliable. If I force a scroll bar to appear, (*ScrollPolicy="on") the scroll bar appears disabled, because it spans the entire size of the box, even though that is out of bounds of the viewable area.
I have this one box at the top of the page that runs off the side of that screen, and that's fine--let it run off the side and don't give it a scroll bar. But I have this other box which runs off the side, which is also acceptable, but I want scroll bars to serve that region and only that region and I want those scroll bars to appear in the viewable area. That is, I don't want to have to move the horizontal scroll bar so that it will allow me to see the vertical scroll bar.
Now the best I could do is as follows: I found the parent of the main box you see in my diagram (which is actually the great-great-grandparent) that never gets bigger than the viewable area, which is an mx:Canvas. Then I force the size of the parent of the box containing my stuff down to the size of the parent mx:Canvas, which then causes the scroll bars to appear where I want. So, it's something like:
<mx:Canvas id="main_canvas" width="100%" height="100%">
a lot of other tags that are parents
<mx:Box width="100%" height="100%" maxHeight="{main_canvas.height}" maxWidth="{main_canvas.width}"> <!--box containing the box that should show scroll bars-->
<mx:Box width="100%" height="100%"> <!--box that should show scroll bars-->
the rest of the tags
The above tags are an abstraction, btw. Due to the enormous number of experiments I've conducted trying to get the scroll bars where I want them, there's a very tall hierarchy of mx:*Boxes, mx:Canvases and even an mx:VDividedBox.
It seems to work, but it's probably needlessly complicated, and I have a feeling that customers will find a way to make it fail.
I'm using the 3.5 SDK.
In the end, the best I could do was wrap whatever I wanted to have scrollbars in an mx:Canvas and then set its maxWidth to a parent component's width that is limited to the width I want, and finally put an mx:Box inside the mx:Canvas. At least, that seemed to work in most cases when controls are vertically stacked and I want a horizontal scrollbar to span the whole width of that mx:Canvas. Usually this was enough and somehow the vertical scrollbar issue sorted itself out, but on a couple of occassions, I had to resort to Flex: getting the height of a collection of controls to calculate the maxHeight of some of the child aggregate controls, which I find a bit kludgy.
I am trying to build a sort of button bar in Flex - something like the horizontally laid-out bookmark bar you'd see in most modern web browsers, where when you run out of horizontal space, you can click on the arrows button(>>) to get a drop-down to see the rest of the items which did not fit into the horizontal space. Problem is, how can I know how much horizontal space is available for me to tell how many buttons to render into the button bar? This need doesn't appear to be support by the general layout manager framework.
You can check the width of the parent container, and if that is less than the combined widths of your objects that you've attached with AddChild or AddElement, then you don't have enough space and need use your arrow functionality.
I'm wanting to implement a scroll bar that snaps to particular values (like windows can snap to the edge of a screen). The idea is that as I drag the scrollbar down it snaps the bar to values as it approaches them.
My scenario is displaying 3 chapters of text. I would like to be able to snap to the beginning or end of a chapter. Of course, to go to the start of the first chapter the scrollbar one can just scroll to the top and likewise with the end of the third chapter. So I'd like to draw two lines on the scrollbar to represent the start of the second and third chapters and then have the top and bottom of the scrollbar snap to those lines. So I'm really actually wanting to use this within a QTextBrowser but I can control a QTextBrowser with a QSnapScrollBar I just don't really know where to start.
Any help would be greatly appreciated.
You could roll your own custom scrollbar class that inherits from QScrollBar or perhaps QAbstractSlider and override the valueChanged(int) signal. Some basic pseudocode:
if currentValue is within 5 of snapvalue1:
set scrollbar value to snapvalue1
elsif currentValue is within 5 of snapvalue2:
set scrollbar value to snapvalue2
...
update/redraw widget
Though I have a feeling that this might seem jerky to the end user.
You could also investigate the pageStep property (which controls how far it will scroll when using the Page Up/Down keys), maybe that could be used to serve your purposes
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);
}
}