I am building a form which contains two forms adjacent to each other. Hence I used PanelGridLayout and placed two panelFormLayout in each 50% width gridCell of first gridRow of a PanelGridLayout. This works perfect with respect to alignment but in a smaller resolution both the gridcell's are overlapping and the fields of left form are overlapping with the labels of the right form.
How can I resolve this issue?
Any ideas on which layouts I can use?
What would you expect it to do in such a case where there is basically not enough space to show the fields in one of the sides?
ADF won't automatically shrink or eliminate fields in such a case.
Acc to the Geometry Management of <af:gridCell>
Beware that if you attempt to use width="auto", halign="center", halign="end" in conjunction with cell content that uses unstable, percentage-based widths, you may experience different results in different browsers. If you wish to use these settings, be sure to constraint the width of that cell content.
Possible Workaround
instead of halign="end" change it to halign="stretch"
source : https://docs.oracle.com/cd/E35521_01/apirefs.111230/e17491/tagdoc/af_gridCell.html
Related
I'm using the SpanLabel Component, but on the screen the text content does not occupying the full width when text size is lower
Someone can help please?
This can happen if the width isn't deterministic. The SpanLabel won't be able to reflow and at best will cause only its own Container to resize. There are two solutions:
Deterministic hierarchy - this is generally best but not always possible
Use TextArea - sometimes this works around the issue by reducing the hierarchy depth.
Deterministic layout means that the size of the elements is determined in a clear way by the hierarchy. E.g. BoxLayout.Y is deterministic on the X axis as it gives the components on the X axis all available space. FlowLayout isn't deterministic as it gives components their preferred size.
Some layouts can go back and forth and vary in determinism based on their axis.
This is important because when we layout the components we go from top down. So we go through the Form to its children asking each for their preferred size. If at this point the SpanLabel doesn't know its size it can give the wrong value and we can't really fix that later as we don't reflow the UI. Reflow would create a potential infinite loop and a performance problem at best.
We try to workaround some of this behavior by making a revalidate() call within TextArea but that has its limits. If the hierarchy is too deep the preferred size is already set and won't adapt. SpanLabel is just a Container with a TextArea and a Label (for the icon). So by only using a TextArea you'd slightly simplify the hierarchy and it sometimes might be enough. E.g.
TextArea t = new TextArea(myText);
t.setEditable(false);
t.setFocusable(false);
t.setUIID("Label");
I'm working on a form that shows many our company's products in a FlowLayout, but on some categories that hold many products, performance in scrolling is noticeably affected. I switched to a List so I could leverage the performance benefits of using a renderer, but now I'm not happy with the layout since there's a lot of wasted space, especially if the device is in landscape mode.
My next thought was to use a Table, which I believe also uses renderers to optimize the display of its data; but to mimic a FlowLayout, I'd need to get the preferred width of some placeholder component, then divide the container's width by that to get the number of columns, and then fill the model with that number of columns in mind. I'd also need to change all that if the device changes orientation.
Before I go down that rabbit hole, I'm wondering if I'm making things unnecessarily complicated for myself and if there's already something that I can use to achieve that goal. So to summarize, what would be the most efficient way to display data (that would be shown as buttons) sequentially from left to right, and top to bottom?
I wouldn't use FlowLayout for anything serious although I doubt its the reason for your performance issues, those probably relate to something else. There is a performance how do I video which is a bit old but mostly still relevant: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
In design terms flow layout is hugely problematic since the elements are not aligned properly thus producing a UI that doesn't look good when spanning multiple rows. I suggest using a grid layout which has a mode called auto fit. By using setAutoFit(true) on a grid of even 1x1 all the elements will take up all available space uniformly based on screen size and adapt with orientation changes.
I'm working on a view that's implementing a multi-column text layout using CoreText (using CTFramesetter).
CoreText usually fills each frame completely, so when I call CTFramesetterCreateFrame with three rects that make up my columns, I get a layout that's similar to the following image:
So the left column is filled completely, the middle column partially and the right column is empty. But instead, I'd like the text to distribute over the three columns so that they take up the least vertical space possible, like in this image:
How to achieve this with CoreText?
I don't mind going low-level here, even drawing each CTRun by hand is an option if necessary.
One idea I came up with would be to create a large frame with the width of a column and then figure out which CTLine to draw in which column. But this has a few limitations:
It would only work if all columns had the same width.
It does not work with clipping paths.
Unfortunately, I'll need to use clipping paths (as in kCTFrameClippingPathsAttributeName) so this idea is out. I could live the fixed column width limitation, though.
Another idea would be to reduce the height until the last frame overflows but that's a pretty brute-force way that surely wastes resources.
(BTW, due to compability requirements the use of TextKit classes like NSTextStorage isn't possible; the resulting view is intended to be used on Mac and iOS, but it needs to work on iOS < 7)
Since there doesn't seem to be a non-expensive way to solve this, here's how I've done it:
I did go with the "reduce the height until the last frame overflows" approach. To reduce the height, I simply have another clipping path (kCTFrameClippingPathsAttributeName) which is a rectangle that fills the bottom of the view to the required height.
The probably most expensive but simple way would have been to increase the rectangle height until finally the text doesn't fit inside the last frame any more.
Instead I've implemented a binary search for that. For my demo app, I usually find the correct height after 8-10 recursions which still is expensive but at least it's pixel-perfect and doesn't rely on any other information other than "did the last frame overflow".
I have a report which displays customer address in multiple labels.
My customers use windowed envelopes for mailing. I need the address labels position to be configurable.
Something like, I'll have a database table which stores the Top/Left position of each label per customer. Based on this table, I need to position the address labels on my report.
I thought, it is doable by expressions, but Location property doesn't provides ability to set an expression and make the label's top and left dynamic.
Anybody, any ideas, on how to achieve this?
As you mentioned, you cannot set an expression for location property. I want to do this before but it seems that there is no solution for this work.
Sorry for the duplicate post
I had the same problem as you did. I got around the problem by using an old HTML trick. It involves using a transparent.gif in an image. You put your image (linked to the gif), then put your label on top. Using a parameter, you can toggle which item to appear by setting an expression in the hidden property for both controls.
As stated by others, it isn't supported. However, here are two ugly work around possible for basic reporting.
Work around with padding.
You can't set formula on the label's location, but you can use padding option instead.
So you can set the label as wide as the report and as tall as the region.
Also, set the label's horizontal alignment to "Left" and Vertical alignment to "Top".
Then, add a formula in left and top paddings to offset the text.
You can also achieve a right aligned offsetted label by setting the Horizontal alignment to "right" and using right padding instead of the left one to offset the field from the right. With the same recipe, you can offset from the bottom by using "bottom" vertical alignment and bottom padding.
The ugly side:
This method will create a mess in the report designer as all dynamic label will overlap each other and take all the space over static label. Also, please note that with this method, you won't be able to do fancy stuff like adding borders around the text and hyperlinks.
Work around with sub report.
If the number of different positions for the label(s) are really low. You can create a subreport for each possibility and use a formula to display the right subreport for the right case. Sadly, this doesn't work for labels in the header as subreport aren't allowed there.
No solution, as it is not supported!!!
From MS online community support...
"As far as I know, the position of the textbox in the report is static not dynamic, so it will not shift to left."
Reference: http://forums.asp.net/t/1433297.aspx
How should I develop a form that can resize nicely?
While that sounds like a simple question the problem I'm struggling with is the fact I'm reproducing an existing application I made in Swing several years back. Its built around a single form that hides/reveals panels as you select different options.
Its around 600 x 700 pixels wide say but its a fixed size window.
Is this good practice? The GUI works fine this way but if you look at other applications you can resize them easily. Granted some applications look stupid full size but should the option be there?
The main screen consists of about five buttons, when maximized this looks ridicilous, but at the same time if the form is resizable the moment you start resizing the form it becomes stupid.
I'm aware of layout managers and so forth so no need to tell me to check these out, my main problem is the fact I can produce an excellent fixed width application but that's about it.
Any advice/links for this?
Personally, I think fixed size forms are a horrible User Experience.
I always try to build mine so that they can be gracefully resized (even if they do look a little odd).
If you're using .NET for your WinForms development, you can easily use a table layout and then anchor your controls so that they resize politely.
A fixed size gui is generally a bad idea because most forms have a user interface element that can sensibly be resized.
First consider a form that only contains two buttons. (A silly form, yeah, but for the sake of discussion we'll assume that it's the right thing for the job) When sized initially in the right way (appropriately for localization, e.g.), there's no good reason to make the form resizable. If you enlarged or mazimized the form, you'd only make the area to click the button bigger, but you'd be clicking a smaller area than the button to resize it, so there's no reason. In this case, it doesn't make sense for the form to be resizable because there's no user-benefit for adding the extra control.
Now consider a form that contains a listview. There are clear usability benefits to making this form resizable in both dimensions. The listview may contain more items than can be shown in a smaller area, both horizontally and vertically, so it makes sense that this form be fully resizable to allow the user to display as much or as little of the data as they want.
Every form control implicitly has certain degrees of freedom either by constraint or by convention. Conventionally, buttons don't resize, so they have no degrees of freedom (even though they can resize). Listviews and listboxes have two degrees of freedom, horizontal to display more data per row and vertical to display more rows. Single line textboxes have one degree of freedom, horizontal. Because they're single line, they don't expand vertically, but they do expand horizontally.
These degrees of freedom help you determine the layout of your form. Form elements that have degrees of freedom should resize in the appropriate direction when the form is resized. I prefer to design my forms with only one control that has two degrees of freedom in an area where areas are typically separated via splitters. I prefer to avoid the explicit table layout panel unless there's a very specific need for it because it's easy to make a form overly complex when there's a table layout to work with. The anchors in WinForms provide an extremely powerful and flexible abstraction for control layout, however, so I strongly encourage their usage.
Aside from the layout panels (my favorite is the table layout), become familiar with the Anchor, Dock (more for the table layout), and MinimumSize properties. They do a lot of work for you when it comes to resizing forms.
Most of your forms will look goofy maximized but my general rules were these:
Buttons stay the same size
regardless of form size (no Top and
Bottom anchor; no Left and Right
anchor).
Buttons stay in the same place with
respect to a border (Anchor
combinations: {Left, Top}, {Left,
Bottom}, {Right, Top}, {Right,
Bottom})
Only the right-most textbox grows
when resizing (Anchor = Left and
Right).
Single multiline textboxes rule the form
(Anchor = Left, Right, Top, Bottom)
With multiple multiline textboxes, the lowest one rules the form.
MinimumSize is less that 640x480 whenever possible; 800x600 max.
The default size is the MinimumSize -- let the users make it bigger if they need to.