Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Posts: 253
Registered: ‎08-14-2010
My Device: Not Specified

Some questions still bother me regarding CUSTOM UIs

[ Edited ]

Hi ,

 

I would like to clear about following questions , I believe this would help for future readers too. Providing a solid answer wouldn't be possible but  answer would  help forever "Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime."

 

 

1. How to determine logically what value will pass into width and height on layout and sublayout ? What are the incidents those could effect for these values?

 

2.When we should set both setVitualExtent-setExtent  and only setExtent in Manager ? 

 

3. If I know the exact height of my custom manger childrens what height I should set for setVitualExtent and setExtent?

 

4.When extend Screen , if I pass a VerticalFieldManager as the delegate and need to be scrollable what value I need to set for layoutDelegate and Screen's setExtent ? How effect each other settings values?

 

5. Style bits that could have high impact on custom manager / screen ? How those effect ? 

 

Thank you in Advance

Developer
Posts: 19,612
Registered: ‎07-14-2008
My Device: Not Specified

Re: Some questions still bother me regarding CUSTOM UIs

There are other better UI people on the forum, but to get you going, here are some answers:

 

1. Not sure this question makes sense.

 

The 'framework' will pass certain values into your method - these are the maximum values and you are supposed to organize yourself in these values as best you can.  Then you return values indirectly using setExtent.  So once your layout or sublayout has been called, other entities, typically Managers, can find out how much space your Field needs by calling getExtent (or getWidth() or getHeight()).

 

If you are invoking this for a Field, then you pass in the maximum values you will allow.  As a simple example, for a Manager this will be the space that is left given values that have been passed in to your method. less whatever you have already allocated to other Fields.  You should test to see what values that Field has actually used by getting that Field's extent on return. 

 

Can you perhaps clarify your question a bit if this does not answer it.

 

2.  I recommend you review this KB article and the followup Threads (expand the comments to see them) to understand the difference between setExtent and setVirtualExtent. 

http://supportforums.blackberry.com/t5/Java-Development/Implementing-a-standard-style-scrollbar-on-a...

The short answer is that you need to specify the virtual size when your Manager is going to be scrolling within a specific area.  So setExtent specifies the actual space on the Screen your Manager takes up, the virtualExtent is the size of the area to be displayed, but you will only see a "window" of the size specified in setExtent at one time.

 

Just as a for instance, it makes no sense to set the virtual extent smaller than the actual extent. 

 

3.  If your Manager is being displayed in a scrolling Manager (so it doesn't have to scroll) then you do not need to set setVirtualExtent.  You can tell this, because you will be supplied a huge value when your sublayout is called. 

 

But if the size you need exceeds the value(s) you are allowed to use, then your Manager had better scroll, and you will need to setVirtualExtent. 

 

Typically you setExtent to the smaller of

a) The space you need

b) The space you are allowed to use.

 

You will setVirtualExtent if the space you need exceeds the space you are allowed to use.  And hope you are a Scrolling Manager. 

 

4. This is beyond my experience, but it is interesting to note that I have never had to use either of these, so perhaps these are not things you need to worry about.  I think a Screen's setExtent will be limited to the size of the screen (Display.getWidth() and DIsplay.getHeight()). 

 

5.This is a difficult question because the effect rather depends on the Manager you add the Field/Manager to, so it is difficult to discuss these in isolation.

 

For a good introduction to this whole area, I recommend this:

http://supportforums.blackberry.com/t5/Java-Development/MainScreen-explained/ta-p/606644

 

 

Developer
Posts: 2,268
Registered: ‎07-08-2009
My Device: various

Re: Some questions still bother me regarding CUSTOM UIs

Some answers (I'm trying to be short, but it is not easy with this topic):

1. It is easy in some cases and harder in others. In general, these values are calculated by the parent manager and passed using layoutChild (which eventually invokes that child's layout()).

 

A Screen will most probably pass display width and display height to its delegate manager.

 

A manager will lay out the fields one by one, giving the first everything it has (either those same width and height or some very big values in the direction the manager is scrolling), then reducing the appropriate size (width for HorizontalFieldManager; height for Vertical; others are not so clear) by the amount reported back by the field (in its getWidth() and getHeight()) before passing them to the next field and so on.

 

2. Peter has given you a good answer on that. Indeed, if a Manager is not scrolling, virtual extent does not matter. Scrolling Managers should lay out their fields, determine their total size and compare that against the size it is given. Then set the actual extent to the minimum of the provided and the total size and virtual extent equal to total.

 

3. Depending on your custom layout - if you, say, arrange them vertically and put some margins between them, calculate the total height by adding up their heights and the margins, then use it in setVirtualExtent and the minimum between what you can have (the height passed to your manager via sublayout) and what you actually need in setExtent.

If your Manager is doing a complicated positionlng of the fields, you'll have to go with the maximum value for the bottom boundary of the fields (their vertical position plus their height).

 

4. I've never used  layoutDelegate, but I can imagine that you might need it if you create a popup-like screen but do not want to use PopupScreen class. Screen's setExtent will specify its size. I believe you'll have to give the same values to layoutDelegate. If you want the delegate to scroll, create it with the necessary scrolling style bits.

 

5. There are quite a few style bits that will have an impact on your custom manager. The scrolling bits affect everything. Stuff like USE_ALL_WIDTH and USE_ALL_HEIGHT might be ignored or respected - your choice. The rest is less important.

----------------------------------------------------------
please click 'Accept Solution' on posts that provide the solution to the question you've posted. Don't say "Thanks", press 'Like' button instead!
Developer
Posts: 253
Registered: ‎08-14-2010
My Device: Not Specified

Re: Some questions still bother me regarding CUSTOM UIs

Hi arkadys,

 

Many thanks for your detailede reply. 

 

could you please bit explain thiese parts further to get a firm idea

 

"height or some very big values in the direction the manager is scrolling".

 

"The scrolling bits affect everything" (could you please let us know where thses affects occur)

 

Many Thanks again , appricaite your help

 

 

Developer
Posts: 19,612
Registered: ‎07-14-2008
My Device: Not Specified

Re: Some questions still bother me regarding CUSTOM UIs

[ Edited ]

Since arkadyz seems to be offline now, let me chip in here again:

 

1) "height or some very big values in the direction the manager is scrolling"

 

You can't explain just that fragment, it does not make sense in isolation, it needs to be read with the rest of the paragraph to make sense.

 

But perhaps an example will help.

 

Say you have a VerticalFieldManager.  Then the width will probably be restricted to the width of the screen.  But the height will not be restricted, because the Manager can scroll.  So it will be a big number.  Now the VerticalFieldManager will give that entire area to the first Field it is asked to layout. That Field will take some of the height and some width.  But in fact VerticalFieldManager ignored the width.  The next Field will be positioned underneath.  So the next Field the VFM lays out will be supplied the same width, but a slightly smaller potential height. 

 

By contrast a HorizontalFieldManager will most likely work within the  bounds of the Display height, but will be extremely wide.  So its first Field will be told it has the full height and the full width.  The second Field will be positioned to the right of the first Field, and it will be told it has the full height, but the width will be slightly reduced by the space the first Field took up. 

 

Please re-read the complete paragraph, I hope it makes sense now.

 

2) "The scrolling bits affect everything"

 

If you look at the Style bits, you will see that there are a number like USE_ALL_WIDTH and USE_ALL_HEIGHT.  In fact these may or may not be respected by the Manager. For example, it is silly to tell a VerticalFieldManager to USE_ALL_HEIGHT.  You usually only want a VFM to use the height it needs for the Fields that are contained within it.

 

Anyway for your own custom Managers, you may or may not decide to check for these Style bits. 

 

However I think what arkadyz is saying here is that the scrolling bits should be respected.  In other words, if you tell a Manager not to scroll, it shouldn't. If you tell it not to display a scroll bar it shouldn't.  So you should always respect these in your Managers. 

 

If I could add one thing.

 

With respect to style bits, you will figure out a lot more when you actually try to do this.  When creating your own Manager, you can choose which style bits you will process.  When you write your first custom Manager you will probably not worry about any.  But later you will possibly come to realize how useful these bits are.  The ones I find particularly useful are USE-ALL_HEIGHT and USE_ALL_WDITH.  Actually not for the Manager itself, but because then the containing Manager knows how big something is going to be every time  it is whatever the containing Manager has passed in to the layout method. 

 

Bascially I think you have been given a really good basis, and you might find it difficult to understand the concepts further without some practice.

 

And one final thing.   There are lots of variations and considerations.  The exact effect of a style bit or some other processing aspect may depend on the exact circumstances.  If you have further questions, it may be easier if you can give a specific example, with code.  Then we can answer for that specific example, and perhaps indicate the differences in other cases.  Attempting to explain all the possibilities, in all the possible scenarios without a concrete example to tie it to, is, I think, going to confuse everyone.

Developer
Posts: 253
Registered: ‎08-14-2010
My Device: Not Specified

Re: Some questions still bother me regarding CUSTOM UIs

Hi peter ,

Once again many thanks for your great explanation , appriciate that !

Just once last clarificartion about question 4.

Let's say I am creating a Custom Screen with a VFM as a delegate. I need to screen to have scrolling effecct so I pass style bit for scorll vertical and show vertical scrol bar. Then I set delegate's extent in the sublayout method passing the width and height what have received to that method params. So what height value will receive by delegate's first child ? Is it height I passed or very large value ? Delegates has to scroll but max height I would get is Display height for custom screen . Where magic happen ?

Many Thanks
Developer
Posts: 19,612
Registered: ‎07-14-2008
My Device: Not Specified

Re: Some questions still bother me regarding CUSTOM UIs

As I noted at the end of my last post, it might be easier if you supply an exact example.  That makes it easier for us to supply the exact answer, and it saves miscommunication too. 

 

But working through your post:

 

"Let's say I am creating a Custom Screen with a VFM as a delegate."

In the following I assume we are talking about this VFM, which is what you seem to be trying to create to match your requirements.

 

"Then I set delegate's extent in the sublayout method passing the width and height what have received to that method params."

The values that are passed in are the maximum values that you can use.  You should in your layout method, figure out exactly what space you do need and that is how you set the Extent.  So you should not just do a setExtent using the passed in values. 

 

"So what height value will receive by delegate's first child ? Is it height I passed or very large value ?"

As noted above, I assume the delegate Manager here is your VFM.  So the first child here is the first Field that this VFM tries to layout.  Now normally your Manager, when laying its first Field out, will supply the size and space it has been supplied.  But if you are creating a scrolling manager, presumably scrolling vertically, then the height that you can give this child is the maximum allowed, because you know that you can scroll. 

 

"Delegates has to scroll but max height I would get is Display height for custom screen"

Remember you have two values, the Extent and the Virtual Extent.  The Extent in this case appears to be the size of the Window through which you can see your Manager's Fields.  But this is a scrolling Manager, so the Virtual Extent is as large you need it to be,  I think this is point of your confusion.  I recommend again that you review the Scroll bar example that I linked to previously.  In that case, the Manager's extent is restricted to the size of the display area, however it uses as much space as it needs to and that is what is specified in the Virtual Extent.  And the scrolling brings areas into view.  You will do the same thing. 

Developer
Posts: 2,268
Registered: ‎07-08-2009
My Device: various

Re: Some questions still bother me regarding CUSTOM UIs

In the case of a custom Screen with VERTICAL_SCROLL and VERTICAL_SCROLLBAR, you first of all create your delegate Manager with the same style bits. You might propagate all style bits from the Screen to the Manager or decide to filter out just the relevant parts (use, for example (originalStyle & (VERTICAL_SCROLL_MASK | VERTICAL_SCROLLBAR_MASK | HORIZONTAL_SCROLL_MASK | HORIZONTAL_SCROLLBAR_MASK)).

 

Now when a Manager is laid out and its sublayout is invoked, you want to check those bits to create a proper behaviour. It might look like this (suppose you are creating a simplified VerticalFieldManager):

protected void sublayout(int maxWidth, int maxHeight) {
  int totalWidth = 0;
  int totalHeight = 0;
  int availableWidth;
  int availableHeight;

  if (isStyle(VERTICAL_SCROLL)) { // will scroll? Give them all the world!
    availableHeight = Integer.MAX_VALUE >> 1; // this is the actual value used in BlackBerry code
  } else { // no scroll? Be modest
    availableHeight = maxHeight;
  }
  // same exercise with availableWidth
  // ...

  for (i = 0; i < getFieldCount(); ++i) {
    Field child = getField(i);
    layoutChild(child, availableWidth, availableHeight);
    setPositionChild(child, 0, totalHeight);
    totalHeight += child.getHeight();
    totalWidth = Math.max(totalWidth, child.getWidth());
    availableHeight -= child.getHeight();
  }
  setExtent(Math.min(maxWidth, totalWidth), Math.min(maxHeight, totalHeight));
  setVirtualExtent(totalWidth, totalHeight);
}

 This code is extremely crude but should shed some light on the topic.

----------------------------------------------------------
please click 'Accept Solution' on posts that provide the solution to the question you've posted. Don't say "Thanks", press 'Like' button instead!