Java Development

[jtp5120]

In order for this to work as I've described, I'll need to nest Managers, as I understand.

• Screen <- [Manager 1] <- [Manager 2]
• Run my same logic described above
• Replace [Manger 2]

I've tried that and nothing shows up on the screen, so I'm guessing that my [Manager 1] thinks it has nothing to paint for some reason.

I've seen posts on nested managers and the inablity to see anything, can I not solve that with Manager.VERTICAL_SCROLL | Manager.VERTICAL_SCROLLBAR | Manager.USE_ALL_HEIGHT | Manager.USE_ALL_WIDTH?

[simon_hain]

you can replace fields directly on the screen. a single manager would be enough to have it replaced.

1. mainscreen -> verticalfieldmanager -> fields

2. replace  verticalfieldmanager with new manager

[jtp5120]

I have been fighting that for what seems way too long.

Here is my constructor and getter for my class that extends MainScreen:

public CoffeeCard(final int cardshellpk) {
  super();
  this.oldVfm = new VerticalFieldManager();
  add(this.oldVfm);
}

public final VerticalFieldManager getVfm() {
        return this.oldVfm;
}

I continually return "oldField is not a child".

try {
  VerticalFieldManager oldVfm = ((CoffeeCard) mycard).getVfm();
  mycard.replace(oldVfm, newVfm);
} catch (IllegalArgumentException e) {
  Logger.debug("Illegal argument: " + e.getMessage());
} catch (IllegalStateException e) {
  Logger.debug("Illegal state: " + e.getMessage());
}

I set a breakpoint at:

mycard.replace(oldVfm, newVfm);

I check the expression, mycard.getManager() and it returns null.

/beating head against my desk...

[simon_hain]

i suggest that you take a step back from your project and simplify your problem.

you are indeed spending too much time on it, better do it on a structured way.

write code as simple as possible that does what you want (mainscreen, manager, replace it).

now go step by step until you reach what you want to achieve. if it breaks in between you will know the reason.

without the complete source of your screen class this is all i can offer.

[jtp5120]

Agreed.

I found something interesting. Even though I've added my oldVfm to the CoffeeCard class that extends MainScreen, I ran the expression:

oldVfm.getManager() and I found that it had a Manager:

net.rim.device.api.ui.container.VerticalFieldManager@c420886f

So, a MainScreen has a default Manager, which makes sense. So couldn't I call CoffeeCard.getMainManager()  to get the same:

net.rim.device.api.ui.container.VerticalFieldManager@c420886f

Then I should do the replace with:

mycard.getMainManager().replace();

[jtp5120]

I stepped back and made a quick sample based on the code found in this message: http://supportforums.blackberry.com/t5/Java-Development/Manager-replace-causing-memory-leaks/m-p/748...

And behold, it worked just fine.

The only difference is when I do my replace I am performing the replace in a Runnable run method call by invokeLater. I cannot see why that would make an ounce of difference.

I have to figure this out, but I'm in an endless loop using all of the suggestions in this thread; one manager on a screen, nested managers on a screen, no managers on the screen - adding, then replacing it.

None of these are working.

[jtp5120]

OK, well I've stripped down the code and the VerticalFieldManager that I want to replace is no longer null.

However, I continue to receive the message "oldField is not a child".

Reading through the API below, what does that exactly mean? I have only one VerticalFieldManager added to the screen, so how is oldField not a child?

public final class MyScreen extends MainScreen {
  private VerticalFieldManager vfm;

  public MyScreen(){
    vfm = new VerticalFieldManager();
    add(vfm);
  }
}

From the API:

Removes a field from this Manager and replaces it with another field. The specified oldField must be a direct child of this manager and the specified newField must not be being managed by any Manager, including this one.

If oldField had the focus and newField is focusable, then Field.setFocus() will be invoked on newField after it is added to this manager.

This method is implemented as follows: After the runtime checks are passed then delete(oldField) is invoked, then insert(newField, index) is invoked, where index if the index of oldField when it was managed by this Manager, then newField.setFocus() is invoked if oldField had the focus when it was managed by this Manager.

Parameters:

• oldField - the field to be replaced
• newField - the field to replace it

Throws:

• IllegalArgumentException - if any argument is null, if oldField is not being managed by this Manager (ie. oldField.getManager() != this), or if newField is being managed by another Manager including this one (ie. newField.getManager() != null).
• IllegalStateException - if oldField.getIndex() returns -1.

[roses_r]

@JTP5120 SO how did you manage to sort your issue? because im in the same situation but this thread has nothing marked as the solution

cheers

[peter_strange]

If you are having this sort of problem, then you can do some debugging, by using

Manager m = <field>.getManager();

where field is the field in error.  You can compare that to the Manager you expect the Field to be in.  You can also try this on the Field you are adding - it should be null. 

When using a MainScreen, be aware that it has effectively the Managers even before you add one.  It has one for the Title area, one for the Status area, and one for the window in between.  In fact, it might have another one for the Banner area, I've never looked.  The point is that you might find one of your Fields has been added to one of the MainScreen managers rather than the one you think it is.