Java Development

[adriangoh]

Hi Guys,

I have a couple of BitmapFields, customized which is embedded within a HorizontalFieldManager. So when i do a onclick, i change the bitmapfield to a larger one, by using setbitmap. The problem is, the whole screen seems to 'jump' as the other bitmaps have to cater to the new size. Is there anyway that i can fix the size of the HFM or BMF so that this does not happen?

Thanks!

[rrr_04]

Hi adriangoh,

You can fix the size of any field by overriding layout or sublaout method of corresponding field. following sample code fix the size of vertical field manager.

VerticalFieldManager vrtclmngr = new VerticalFieldManager(){ 
    protected void sublayout(int maxWidth, int maxHeight) {       
        setExtent(_widht, _hieght); 
        sublayout(_width, _hieght); 
    }
}; 

 Thanks

R.Jain

[adriangoh]

thanks dude. i'll try that. will post the result later.

[arkadyz]

---

rrr_04 wrote:

Hi adriangoh,

You can fix the size of any field by overriding layout or sublaout method of corresponding field. following sample code fix the size of vertical field manager.

VerticalFieldManager vrtclmngr = new VerticalFieldManager(){ 
    protected void sublayout(int maxWidth, int maxHeight) {       
        setExtent(_widht, _hieght); 
        sublayout(_width, _hieght); 
    }
}; 

 Thanks

R.Jain

---

That's an incorrect piece of code.  3 problems:

1) calling sublayout inside itself - makes a recursive call which will cause StackOverflowError.  You probably meant super.sublayout.

2) calling setExtent before super.sublayout will achieve nothing - super.sublayout will set the extent on its own, overriding your setExtent call.

3) maxWidth and maxHeight are called that for a reason - you should not exceed those limits.

A better approach would be like this:

VerticalFieldManager vrtclmngr = new VerticalFieldManager() {
  protected void sublayout(int maxWidth, int maxHeight) {
    int realWidth = Math.min(_desiredWidth, maxWidth);
    int realHeight = Math.min(_desiredHeight, maxHeight);

    super.sublayout(realWidth, realHeight);
    setExtent(realWidth, realHeight);
  }
};

[rl_interface]

Hi

you can use encodedImage use scaleImage32 method with HorizontalFieldManger width hieght.

[arkadyz]

---

rl_interface wrote:

Hi

you can use encodedImage use scaleImage32 method with HorizontalFieldManger width hieght.

---

Yes, you can go that way too - just pre-shrink the image so that it doesn't cause the re-layout.  Pick your method (setting the extent or scaling the image) according to what you want the user to see.  If you can, do not scale the images on the UI thread - do that on a separate Thread.

Oh, and don't forget - you almost never have the HFM's actual height available - it is calculated inside the HFM's sublayout which is probably too late for you.  Just pick the height you want to use and stick with it if you go that route.

It's good to have options.

[adriangoh]

hi there, i've tried your suggestion for using super.layout and then calling setExtent and it seems to set the width and height of my VFM. However. i have a problem with the individual child fields within this vfm. I tried using layoutChild and then calling setPositionChild with minimal values but i don't see the change. The bitmapfields are still of normal size.I.E. Their individual with and heights do not seem to be affected

Here is a snippet of my code

    protected void sublayout( int width, int height )
    {

            for (int i = 0; i < numberOfFields; i++)
            {

              Field field = getField(i);

              layoutChild(field, 5, 10);
              setPositionChild(field, i*10, i*10);

           }

            super.sublayout(myWidth, rowHeight);
            setExtent(myWidth, rowHeight);

     }

[swati-srivastava]

y dont u try scaling its the right way

Moreover i think u should do like:

   protected void sublayout( int width, int height )
   {
         super.sublayout(mywidth,rowheight);//must be called firstly
            for (int i = 0; i < numberOfFields; i++)
            {

              Field field = getField(i);

              layoutChild(field, 5, 10);
              setPositionChild(field, i*10, i*10);

           }

           setExtent(myWidth, rowHeight);
     }

[mbasheerk · Accepted solution]

try after removing

super.sublayout(myWidth, rowHeight);

[arkadyz]

---

mbasheerk wrote:

try after removing

super.sublayout(myWidth, rowHeight);

---

Exactly!  To elaborate a little - think what super.sublayout() is supposed to do.  It should lay out the "children", ask them about their dimensions, position them and calculate its own extent.  That is why I said "put setExtent after super.sublayout", and that's why super.sublayout overwrites your efforts at laying out and positioning the managed fields.

Another note: if you decide to completely remove super.sublayout, you must also set virtual extent.  It is not used if you specify NO_VERTICAL_SCROLL | NO_HORIZONTAL_SCROLL, but if you want any kind of scrolling, it is mandatory (especially on touch-screen devices).  Virtual extent is the full size of your Manager's area.  If total width/height of your managed fields is bigger than your visible dimensions, you'll have to deal with that.

Of course, fully implementing your own sublayout is much more complicated than just setting extent and position of a few fields. However, if you know your screen layout exactly beforehand, just do everything "hard-coded" and don't look back.  Also, consider extending Manager rather than any off-the-shelf container such as VerticalFieldManager.  You are already overriding its (Manager's) one and only abstract method (sublayout) and are not going to call super.sublayout() anyway.  If you know or can calculate your exact dimensions in advance, override getPreferredWidth/getPreferredHeight as well.