We try to use the treefilter in IcCube to show categories with subcategories. Now we discovered two problems, we don't know, how to fix:
We have 15 categories on level 1, but only the first 11 of them show. There is some space underneath, so it doesn't seem to be cut due to rendering:
We are not able to activate a vertical scrollbar, so when we unfold the tree, there are parts we cannot see anymore. The hotizontal scrollbar is there, but once the tree is too big (image 2) it can't be used anymore as well.
Did we do something wrong and there are options we didn't see, or are our problems due to some bugs in this widget?
Point 1)
Try to increase Max Member Count property on the Query Wizard tab of the widget (this number is for all the members to be managed, not only level 1 items)
Point 2)
Try adding {"cssStyle":"overflow:auto"} in the Content CSS property of the Box tab of the widget.
Related
I want to use kendo-ui-grid server paging with virtual scrolling and encountered a problem I don't know how to solve
It's shown in here:
http://dojo.telerik.com/uyEje
Try scrolling to row number 2M.
Anybody has any idea?
According to the Kendo UI documentation ...
"Virtual scrolling relies on a fake scrollbar. Its size is not determined by the browser, but is calculated based on the average row height of the data that is already loaded. As a result, variable row heights may cause unexpected behavior, such as inability to scroll to the last rows on the last page. To ensure that all table rows have the same heights, use either of the options: (1) Disable text wrapping. (2) Set an explicit row height that is large enough (as demonstrated in the following example)."
Loving XCode 6/iOS8's new way (using size classes) of doing Autolayouting (despite it being a pretty hard puzzle to solve at times).
But how does one reset one of the size classes back to Any/Any?
Set you size class to wAny hAny
Now you should see constraints installed outside this size class as greyed out in the pane on the left:
Select this constraint in the list and in the detail inspector pane on the right you should see this:
Here you see I installed a wRegular hAny constraint.
Hit the little x to delete this constraint in this size class.
Repeat for any other constraints you have.
Once these constraints are no longer installed in any size classes you can select and delete them in the left pane.
When you click on the Width/Height, take your cursor to the middle square and select it. That will set it at Any/Any.
Edit: I think I may have misunderstood. If, for example, you are working in wCompact hRegular, and you don't want those changes anymore and you want it to "inherit" from Any/Any, then you'll have to go about either uninstalling or deleting the constraints you created specifically for that size class. When you have your view controller outline showing, and the constraints appearing, the ones not grayed out are active for that size class. Check each one to see if any are specific to the size class you're working in (such as wCompact hRegular).
You can also uninstall or delete any additional UI objects you added to that size class specifically.
Hope that helps.
I cannot find any reference to this on SO.. The full message is:
"This application is trying to draw a very large combo box, 32 points
tall. Vertically resizable combo boxes are not supported, but it
happens that 10.4 and previous drew something that looked kind of sort
of okay. The art in 10.5 does not break up in a way that supports
that drawing. To avoid breaking existing apps, NSComboBox in 10.5
will use the 10.4 art for large combo boxes, but it won't exactly
match the rest of the system. This application should be revised to
stop using large combo boxes. This warning will appear once per app
launch."
Any ideas what to do about it?
I made the box in IB, and don't think I did anything special to create it.
I had this same issue. The combo box was in a cell in a table. I changed the row height setting of the table to automatic. But, this gave me an error for not being a valid setting for a cell based table. However, when I reset the table's row height to fixed, the message went away.
More Google searches seem to indicate that this has something to do with the height of the combo box. In my case, the row height of the table increased when I reset it from "Automatic". Perhaps this will give you something to go on.
I had the same error. When I dragged comboboxes out of a Stack View, Xcode messed up their heights. To correct the problem, I added height constraints of 22 to each of them. That caused the warning. When I deleted all the height constraints, the warning went away. The comboboxes didn't revert to the crazy heights they had when I dragged them out.
I've had this forever, but ignored it because I had no idea why it was happening.
From reading the other answers here...
From the storyboard I edited the Combo Box Cell inside the combo box. I changed the Cell Size from Regular to Small and back to Regular.
The problem went away.
I am using a ZedGraphControl in a WindowsForms project in C#. The ZedGraphControl is V5.1.5.
The data in the control is static and I add it all before the form is shown. The X axis of the data consists of numbers indicating seconds offset from the beginning. in other words from 0 to some number of seconds.
I want to initially show the last 5 seconds, but provide a horizontal scrollbar so the user can scroll back and forth. I set the "graphPane.XAxis.Scale.Max = maxX;" where maxX is the largest X value in my data. I set the "graphPane.XAxis.Scale.Min = maxX - 5;".
The data starts off displaying the way I want it, but when the user scrolls the horizontal bar, bizzar behavior occurs.
As you drag the thumb of the scrollbar to the left, the beginning of the data shown in the grid moves to the lower values as expected, and the thumb of the scrollbar moves to the left, but the right edge of the thumb stays at the right of the scrollbar and you cannot move back to the right. It is as if the data to the right of the viewing range gets truncated as you scroll left.
I cannot find any reason for this nor any way to control it. Does anyone have any ideas about this behavior?
Ok, found it myself.
I found a fine article that describes scrolling:
Add a ScrollBar
In it the author specifically says "the scrolling will be wacky because the scrollable range has not been set".
I used the sample "Manually Setting the Scroll Range" and the part that I was missing is setting the zedGraphControl1.ScrollMinX and zedGraphControl1.ScrollMaxX properties. Once I defined these values everything started working as expected. I also found that in my case, the value of zedGraphControl1.IsAutoScrollRange had no effect, but I left it set to false to be consistent with the example. This would probably have an effect if the dataset is dynamic.
I've found many answers, here or inside MS' UI guidelines, regarding button positioning, but none about how to position (in which order) buttons when you have three actions to do, New, Edit and Delete.
I have a simple UI, in the upper part I placed a grid listing some data. Beneath, these three buttons. Following what I see around, I have to place them in this order:
New - Edit - Delete
But it seems to me that the delete button is more prevalent and easier to reach and click than the others (it falls on the lower-right corner of my window).
Any suggestion?
I think the order you cite (New - Edit - Delete) is most common because you would logically tab order from left to right when using the keyboard. New would arguably be the most used button (possibly edit depending on the application, but rarely delete) and therefore you wold want the fewest tabs to get to the New button.
Column layouts are always good for these kind of buttons, as one has to move the cursor into the button area, which is horizontally slight and therefore less likely to be accidentally clicked.
Also it provides a perceived division from the main GUI widgets, instead of spanning their length, which tends to create less of a perceived division in the user's mind.
But if you do not wish to change the overall layout, I would say that your current layout is good. Maybe add a delete confirmation box if one is not already present.