I decided to give SwiftUI a go but I seem to be having a bit of a blonde moment here.
All I did was create a Form to which I added few Text objects. Due to the limit of 10 per parent view, I added the objects to Groups.
When adding new Groups inside the same Form, I noticed that the first object of the Group gets added behind all the objects in the Group above as well. Seems like a weird feature, but it's entirely possible that I'm just being thick here.
I can get rid of the overlapping by adding a Spacer, an empty string or changing the Group to a Section for example. But what would be the solution if I want it to be one long list without any separators?
Group is not a container, imaging it as a transparent thing, which just inserts its content at the top of the available space. So you have two consequent groups, so from layout perspective the top starts for them all at the beginning of Form. That's why group content views overlap, and that's why they are not if you insert some separator between groups - top of each group proposed by Form is different.
In your use-case I would recommend to use VStack instead of Group.
Related
I am looking into sub-classing a container component to act as a "listbox" container of sub-classed TPanels that are acting as "listitem" members. Basically, my CustomListItems are TPanels that contain some images, labels, and/or other controls. These CustomListItems will be created dynamically and will have dynamic sizes. Their widths shall be equal to that of their parent container, but their heights might differ.
I want my container "listbox" to mostly behave like a standard TListBox, in that it shall be vertically SCROLLABLE, and that the added items shall be stacked on top of each other in the most automatic way possible. For example, doing:
CustomListItem* myCustomListItem = new CustomListItem(this, param1, param2, param3); // this = TOwner
myCustomListItem->Parent = myCustomListBox;
will automatically position the added child TPanel item in the first vacant slot of its CustomListBox container.
What I am seeking is the most standard way for implementing this parent/child, container/contained relationship. I am unsure what container component to sub-class and how to go about this. I am considering two approaches:
Possibly using a TLayout, TGridLayout, or TGridPanelLayout container if it is vertically scrollable and if it will handle rendering/positioning the added child TPanels (my CustomListItems) automatically.
If there is no "easy" or "standard" way to implement the above behavior, I would maybe consider using a plain TVertScrollBox as the "listbox" container, and then custom-handle the positioning and repositioning of the added items "manually".
For the latter approach, what I need is information about which events might trigger the insertion and removal of child items, and how to handle those events properly. For example, I would keep track of added items and their positions relative to the parent container. When new items are inserted, I can then manually handle positioning them correctly in the container. I can do that "internally" by overriding/overloading (not sure) the AddObject method, but I would still need to handle certain events for "external" insertion/removal of objects (e.g: myCustomListItem->Parent = myCustomListBox;)
I hope I made my question clear enough. Any help would be highly appreciated.
I am trying to create a Google Spreadsheet which is able to count the number of items, and also be sustainable when I add new items which won't affect the previous result.
The table at the left is the data, and on the right is the result I am looking for Example:
The two items in RED box are newly added, and the yellow cells show the results expected.
Basically, when there is a item is bigger than ZERO, I want it to be counted. However, I don't want the previous result to change when I drag the function across.
I tried to use the combination of =counta and vlookup, but it is not working properly.
Assuming your red box is around B8:E9 then in H3 copied across and down to suit:
=COUNTIFS(C:C,"<>"&0,$B:$B,$G3)
will give the results you show (other than the highlighting). However, two more days of data and one table may get in the way of the other. You might want to relocate one table above the other so each has room to expand - or move one to another sheet which would then require sheet references to be added to the above formula.
I am not clear what issues you have had with whatever combination of =counta and vlookup you have tried.
I am looking to improve my app's signup and login form from standard text boxes to using table rows (or something similar).
I am pretty much inspired by the forms which SnapChat have created, which you can see below...
I'm trying to figure out how they accomplished this, and am thinking it must be a table view with 3 cells (Static?), and the text below is part of the footer of that selection of cells.
How is one able to then capture data into it directly?
Am I right in maybe assuming that each cell is 'custom' with a text field in each one (with placeholder text) with a no-borders style on the text field?
Or has this been achieved via some other way?
Keen to hear your thoughts. Thanks!
You absolutely could do that with a table view. But I don't think this one is. Notice the divider lines start at the far left rather than at 15 pixels in (with the text). The separator lines are also two pixels tall rather than one. So I'd say it's a safe bet that it's just a simple view with 1 pixel tall UIView's for lines.
I'm interested in creating a report that contains a group in it.
I'd like the group to be enclosed in a box where the box surrounds the group in every page I've tried this using lines and placing them in such a way that there is one on the group header, two on the sides, and lastly, one on the footer.
The issue always appears when the data in the group overflows to a new page, and the footer of the group does not print. Ultimately I'd like to go from something that looks like a box missing the bottom line to one that is fully closed on every page.
I'm not sure I have understood your question, but try taking a look at using a region, with all members of the group in it, including the lines/shape used, you can then group the items together.
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.