I would like to use FormLayout where one of the fields is visible depending on another field. Is there a way to keep the formatting the same, that is for all the fields after it to stay in their same position when another component is invisible.
Below is the code to reproduce as well as a screenshots of what I would like compared to the current behavior. In essence each time you select the combobox you make the "Year Joined Team" field invisible/visible.
TextField nameTextField = new TextField("Name");
ComboBox<String> teamComboBox = new ComboBox<>("Team");
DatePicker yearJoinedDatePicker = new DatePicker("Year Joined Team");
TextField moreFieldsTextFields = new TextField("More fields");
FormLayout formLayout = new FormLayout();
formLayout.setWidth("600px");
formLayout.setResponsiveSteps(new FormLayout.ResponsiveStep("0", 2, FormLayout.ResponsiveStep.LabelsPosition.TOP));
formLayout.add(nameTextField,
teamComboBox, yearJoinedDatePicker,
moreFieldsTextFields);
teamComboBox.setItems(List.of("One", "Two"));
teamComboBox.addValueChangeListener(change -> yearJoinedDatePicker.setVisible(!yearJoinedDatePicker.isVisible()));
formLayout.setColspan(nameTextField, 2);
add(formLayout);
Ideally the goal is to have the fields below the yearJoinedTeamDatePicker component to stay below so that all other components below continue to be aligned correctly when it's set to be invisible.
Instead what actually happens is that all the components are shifted on field to the left, as if the invisible component is no longer part of the FormLayout. Meaning the moreFieldsTextField is now on a different row, and if everything is setup for two columns every row will be incorrect. I understand that this makes sense in some context but in a FormLayout is there a way to keep the form formatted if a component is invisible?
If for example I had firstname and lastname as two side by side fields they would now be on different rows as shown below:
A very hacky solution would be to add in a Span component or something like that and make it invisible when the yearJoinedDatePicker field is visible, and invisible when it's visible. Basically fill it in with an empty field when it's invisible. That is a hacky workaround but it doesn't seem like an appropriate solution. With that in mind is there a way to keep the formatting/layout if a component is invisible?
What you are trying to achieve is sort of defying the purpose of FormLayout. FormLayout has css flex rules to wrap elements / components by row. Thus if you switch visibility of a component, the behavior is as you described.
One thing you could do, is to wrap "Team" and "Year joined team" inside e.g. HorizontalLayout and set
formLayout.setColspan(horizontalLayout, 2);
See, also my previous answer about FormLayout https://stackoverflow.com/a/69270190/8962195
If you want to keep the place, maybe it's vable for you to set the field ti disabled with setEnabled.
I'm not sure how it would behave, but you could try CSS display: none instead of the setVisibility(false).
Related
I have a Vaadin 22 application that features a view that has 2 Select fields next to each other. They belong together (are actually dropdowns for month and year) and they require only a single label, which is longer than the component on the left.
I've tried to put it on the left component but then it gets cut off:
What is the easiest way to accomplish this?
It seems you might want to try the Custom Field component for this.
Another alternative is to customize the CSS a bit:
vaadin-select::part(label) {
overflow: visible;
}
I've customised the style of a Firmeonkey list box item in such a way that now it can consist of 4 TLables in it. Each of the lable has Alignment as alNone.
I'm setting position of each of them in my code whenever i need to add any item. I've observed that when my list has scroll bar and if first component is not visible (i.e. i've scrolled down enough) at that time if i re-add all the items again in list box, then the position of TLabels in first items (or items which are not shown) get distorted.
For setting positions I am using below code :
(tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Position.X :=
(tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Position.X + (tmpListBoxItem.FindStyleResource('txtCol2') As TLabel).Width;
Any suggesstions, how can i overcome this issue.
Regards,
Padam Jain
Firemonkey styles are repeatedly 'applied' and 'freed' as components appear and disappear from screen.
It is not enough to simply set properties of style objects once and expect those values to be remembered. What you need to do is either listen to the OnApplyStyleLookup event or override the ApplyStyle method of a custom component and use the same you have above to set the properties again.
This means you'll need somewhere to store the values you are going to set.
I would suggest for your situation that you subclass TListBoxItem so you can add suitable properties or fields and put your code in ApplyStyle.
I am using TDBGrid for the first time.
I didn't even notice the Columns property in the object inspector and everything went just fine: the grid was filled.
Then I saw the Columns property and tried it. When I use the object insector to add items to the Columns property of the grid, they do not all of them show up at run time. To me, it looks like the FieldName property is important. It looks like it is correct, but there are no values in some columns.
If I leave this property blank (no columns at all) it seems that the control populates it itself at run time and I do see all the columns. I could live with that. When I set column titles at run time it works, but setting column width does not.
[Update] Thanks for the feedback. I am learning slowly. Now I see what is happening. I wanted three of the five columns to be calculated. Two are gotten from INNER JOINs and the third from an SQL 'cast' of SELECT ... FROM_UNIXTIME(<table>.time_stamp).
If I do not define the columns at design time then these values are populated at run time when I execute my SELECT. Cnn anyone tell me how to set things up at design time? Thanks
There is no difference in functionality between runtime and designtime set up columns. That is: what can be done designtime can also be done runtime, and vice versa.
When te Columns property is kept empty, the grid fills it by default with all fields it finds in the linked dataset, once the dataset is opened. All column specific settings, such as alignment, width, title caption, etc... are set to default, based on the type, length and name of the corresponding field. This is the lazy way which sure could be sufficient.
You could deside to use your own setup or modification of the columns property, for one or more of the following reasons:
Change the order of the dataset fields in which they must appear in the grid,
Truncate the width of text fields (especially VarChar fields or Char fields with a large length normally result in colums that are too wide for normal presentation and/or user interaction),
Change the alignment of the fields (normally numeric fields are right aligned by default),
Hide one or more fields from the dataset,
Etc...
These own settings can be done desingtime as well as runtime.
Using the designtime columns editor is the preferred and RAD way in need of these customizations. Open the editor by double clicking the grid or the property, or via the grid's context menu. If the linked dataset is active then the command Add all fields is enabled, which does exactly the same as if you did not select any field at all, i.e. the default behaviour as described in the second paragraph.
The best way to define the columns on a dbGrid is to doubleclick the dataset in order to create variables that the form knows about (persistent fields). You can edit various properties of these variables such as DisplayLabel, DisplayWidth and DisplayFormat.
You can also add calculated fields by double clicking on the dialog box which appears when you double click on the client dataset.
I've got an interesting problem that I'd like some advice and opinions on if you would be so kind. I'm not after code as I prefer to write that for myself. My background is J2ME and Android but I've recently taken up Blackberry.
What I need to write is something akin to the Android ListView albeit a little simpler.
Each row consists of 3 items. There's an image/icon, a multi-line (2 or 3 row) text element and an imagebutton of some form.
However, each row has only 2 columns. The icon/image & multi-line text are combined for the first column and are clickable (with both the column (0) plus the row ID identifiable). The next element in the row (1) is a clickable image (common to all rows - this also needs to have an identifiable row ID). There must be different actions for each column/row cell.
There is a need for multiple rows to be scrollable vertically and there may well be a lot of items.Each row needs to fit the screen width with the icon/multi-line text justified to the left and the clickable image justified to the right. Each row needs all of its components vertically justified (possibly centred) for neatness.
So what we have (for a row) is:
[clickable image/multi-line text combo][clickable image]
Ideally there will be a common background (gradient shaded) for each row once focussed. This should span both columns seamlessly.
Any thoughts would be most appreciated.
The simplest approach is probably to have a VerticalFieldManager for the list, populated by HorizontalFieldManagers for the row.
As for the inner part of the row (the columns) you can pass FIELD_LEFT to the first field and FIELD_RIGHT for the second for alignment. The image-multitext field you can create yourself by extending ButtonField and overriding the paint method. You can use the Graphics object to draw your image and text. A different approach (and perhaps a simpler one) is to extend the HorizontalFieldManager, add your components and make it clickable by capturing the click events.
One thing to realize about Blackberry is that there are many ways to do something, if one thing doesn't work quite the way you want it to, try something different. Hope this help you get started!
Is it possible to add gui components to blackberry screen beginning from the bottom instead of the top ?
Thanks
A quick response would be no but let me explain why and suggest afew work arounds;
Screens don't actually handle the laying out of fields onto themselves, to do this they delcare a delegate manager which can be any type of manager, vertical, horizontal etc. The problem is all managers begin painting themselves from the top left. For a manager to paint fields starting from the bottom it would have to know exaclty where the bottom is located and add components up rather than down which goes against all the low level code inside the manager class. You can read more on managers in the BlackBerry API documentation.
You could still achieve an effect similar to this though by tweaking how you add fields and playing with field styles. For example consider this code:
add(new LabelField("field 1"));
add(new LabelField("field 2"));
This would give us the results;
field 1
field 2
because field 1 is drawn then field 2 below it. However if we were always to insert fields at the begining of our manager e.g. position 0 like so:
insert(new LabelField("field 1", FIELD_BOTTOM), 0);
insert(new LabelField("field 2", FIELD_BOTTOM), 0);
We would get the results;
field 2
field 1
Which is the results you'd expect from a screen described in your question.
I'm not really sure how you'd get the fields to paint to the bottom of a screen though, you could try researching the "position relative bottom" styles but I'm honestly unsure.
You are probably using a VerticalFieldManager, and the documentation on that says:
A vertical field manager lays out
fields top to bottom in a single
column.
So if you
manager.add(field1);
manager.add(field2);
manager.add(field3);
The order of the fields on the screen will be just that.
But you could do something like this:
Vector v = new Vector();
v.add(field1);
v.add(field2);
v.add(field3);
for(int i=v.size()-1;i>=0;i--) {
manager.add((Field)v.elementAt(i));
}
Sort of. You can use the Manager#insert(Field, int) method and always insert at the zero index. If you do this with a VerticalFieldManager, it would simulate a bottom-up adding of Fields to the Manager.
Some of the answers so far are to use Manager.insert(Field, int), and keep inserting at position 0. This will work, but the running time of the insert is linear in the number of elements already added to the manager. Meaning this solution will have an overall quadratic running time. Not a big deal if you're adding under 10 fields, but if you're planning on adding more than that, the insert overhead will be substantial.
If you can do the inserts top to bottom, by reordering the fields as Muger's solution suggests, the running time will be much improved.
Finally, you can write your own BottomUpVerticalFieldManager that does the layout the way you want. When you write your own manager, you can layout the fields in whatever way pleases you. In this case, it would be bottom to top. Writing your own manager may seem daunting, but it will give you considerable freedom in the future when trying to solve layout issues.