I have been trying some UI stuff on BB devices and I'm a bit confused between setMargin and setPadding functions of the Field class. I know their definitions but I dont get when I'm supposed to use either of one for any field.
Any help, examples would be highly appreciated!
Thanks!!
Difference between setMargin() and setPadding() will be clear by the fig. below
setMargin() sets the margin of one field from the other field as shown in fig.1
and setPadding() increasse the area of the field on which you are setting the padding. As shown in fig.2 the extent of Button2 become increased, while in setMargin(), the extent of field remains same and the spacing between the field become changed.
Related
I have following text in UILabel. I want to underline both text. and give them click event and open related link.
I Agree to the Terms & Conditions and Hotel Booking and Cancellation Policies
but problem is I couldn't give separate click event for both underlined text.
What is the best way to do that?
I know one option give separate label for all four string. but it is harder to maintain position of all that label for different sizes
Appreciate for help!!!!
take a look of this library Might be it will help you: https://github.com/TTTAttributedLabel/TTTAttributedLabel
Suggest to change the UI design. A possible work around I found is add UILabel below this text label/button with text contains a number of under scores(_) and pin it with auto layout. N.B: It's never ever a good practice at all.
If I set mycoolbar.fixedorder to true,only the grip on the first band will be hidden.
Well,If you use Delphi 7 to create an VCL Forms application,then put a coolbar on it and create 3 coolbans to hold other controls,only the grip and the top coolbands can be hidden by setting mycoolbar.fixedorder:=true.
I've uploaded a picture to make things clear.
You probably got a FixedOrder property wrong. The fixed property does not allow bands to be rearranged if set to True.
Setting up property of CoolBar to True keep user from changing the bands order at runtime, but the user can still move and resize the bands. I can actually give you advice what you can do, but the actual solution for your problem, well, you will have to wait for another answer.
My advice is to use three CoolBars in a row and setting their "FixedOrder" property to True and BandBorderStyle to bsNone. That way the grip will be hidden on all of them.
About the property, it's not a bug of IDE, it is the actual preference of the property.
I am struggling to assign a style to a TGrid within Delphi Firemonkey. Styling required is quite basic (ie. Align the text in a column and colour per value).
For background, I have created a TGrid, set the rows (eg 200), and added the number of columns (3 in this case). The columns have been labeled as "Code", "Company" and "Balance". As the grid does not contain values (like a TStringGrid), I am able to set the display value via the "GetValue" method (where I retrieve data from an external source). - The result is a list that is fast, and able to cope with a lot of data, the downside is I can not format the design at run time...
I am thinking that I may have to use "Styles"; that are new in FM. If this is the case however, I am not sure how I can reference the cell as it does not really exist as it is painted via the GetValue method when it needs to be drawn?
Any help appreciated,
Regards
Ian.
Ray Konopka's blog might help you here:
http://www.raize.com/Articles/FmxStringGridCellFonts.asp
You can apply a style to a Column by creating the OnApplyStyleLookup event to the column, but to set the font style and color etc you would still need to implement a OnApplyStyleLookup for the TTextCell's themselves too.
I posted a very similar query on Stackoverflow and then found a workable solution which I added here
firemonkey mobile grid with livebindings - changing TextCell text color at runtime XE5
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.
I have an application, where there are many forms which follow visual form inheritance.
Every form has standard delphi components as well as custom components.
Form validating functionality needs to be added. That is, A small red circle or astric image needs to be drawn next to a control, if the control's value is not valid.
This drawing functionality has to be available through out the application on every control.
What is the best way of implementing this functionality? Is there any design pattern that can help?
Thanks & Regards,
Pavan.
JEDI's JVCL has the TJvValidator component that will do just that for you. Here's a link to the TJvValidators container to get you started.
Something I have done in the past in my validate method was to change the control color to $00C4C4FF for any value which fails validation, or clWindow if it passes. (I use a constant clInvalidEdit). On projects where I am also using Raize controls with a flat border, I also adjust the border to clRed. My required fields generally have a color of $00B0FFFF (again a constant clRequiredEdit).
Most often, I'll create a method named ValidateForm which returns a boolean if the form is valid, or false if its not. The validateform checks every field for validity and adjusts colors where needed, and set the active control to the first field which fails.