Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
03-21-2010 08:23 AM
"I would drop a little knowledge on you here"
Never really got into paintBackground - thought it was for a Screen object and not a Field. Just to simplify,, the issue I had with setPadding was in a Field that was added to a Manager. The Manager's background was an image, but the padding on the Field did not seem to get repainted. I was probably using it incorrectly, but since there is no documentation I didn't how to correct the problem.
I have seen the KB article and was at the session at DevCon when the presenter said setPadding could be used. I was not saying that that you should not use it, and in fact I do use it in some places (where there is no background to worry about). What I was trying to say is that perhaps these things have not been released because they are not 100% finished or stable or there are some funny quirks that RIM would find it difficult to document.
But thanks for suggesting I try paintBackground. Next time I need some padding on a screen/manager with a background, I will try it!
03-21-2010 10:52 PM
Yea, setPadding + paintBackground were how you put a rounded border around things pre 4.6. The other things to know, paint() gets the Graphics object the size of setExtent() paint background gets the setExtent plus setPadding
03-21-2010 11:13 PM
i am knot working for RIM. official statement is: do not use them. my own statement is: do it at your own risk.
I find RIM's official position irritating because they violate it themselves so often. For instance, you can view an "official" RIM webcast (or at least still download the slides) here that publicly recommends using getPadding/setPadding!
I (sort of) agree with Simon, though: use at your own risk. Just because an API has been there for ages, does exactly what you need, and is (apparently) relied on internally by RIM, it may still disappear in the next software release. (Of course, documented APIs are frequently deprecated and sometimes unavailable in new releasese, too. But at least then we can righteously claim that RIM broke their API contract.)
03-22-2010 04:54 AM
"they violate it themselves so often".
Is this really justified? set/getPadding is the only occasion that I am aware of, where RIM have said that an undocumented API can be used. Can you point us at any others?
03-22-2010 05:05 AM
when i look at the sorry state the API documentation was when i started, and that it was only improved a bit recently, i rather think that some of these methods are not documented because nobody checked the docs AND saw it. Or: RIM is a big company, there may be one department thinking it safe to use (and showing it on webinars), others think its not safe and don't include it in the docs.
You can speculate around but it won't change a thing.
03-22-2010 11:21 AM
Speaking for me I have seen setPadding(int arg0, int arg1, int arg2, int arg3) in Eclipse. I thought that this method could be handy for me and wanted to know which side of the component which parameter is referring to.
Usually Eclipse takes the Javadoc or the source code (if available) into account to show the real parameter names and the rest of the documentation. Not here, obviously.
So finding this was rather a coincidence - I am not actively comparing the jar files to the APIs.
03-22-2010 01:59 PM
"they violate it themselves so often".
Is this really justified?
No, it's not justified. I retract what I wrote.
I think that my overstatement was born of an irritation that I definitely feel. It seems to me that there is a steady trickle (just a trickle, but steady nontheless) of inconsistent information from RIM. The most recent example that comes to mind is someone from RIM advising us on this forum to use the preprocessor variables that are set by the Eclipse plug-in when switching target JDE versions. When asked where these variables were documented, someone from RIM explained that they weren't actually available to us.
I also stand by my statement that documented APIs aren't an ironclad guarantee. For instance, the requirements for the Bitmap in "new Graphics(Bitmap)" are incompatible between 4.6 (Bitmap.COLUMNWISE_MONOCHROME or the default type of the device), 4.7 (Bitmap.ROWWISE_MONOCHROME or the default type of the device), and 5.0 (default type of the device only). Sadly, after 4.7 there appears to be no (documented) way to create a Graphics for drawing into a monochrome Bitmap when running on a color device. (I have a bee in my bonnet about this because it tripped me up.)
The quality of RIM's documentation might be acceptable if they were putting out a relatively new product. But huge parts of the API have been around for years and some of the bad documentation (like broken links in the crypto api docs) ought to be fixed by now.
Enough of my complaining. Here's a suggestion. RIM should set up the documentation as community-based, wiki-like documents, with some mechanism for the entire BlackBerry development community to contribute. After all, anything that makes the community as a whole more productive will benefit not only us but RIM's bottom line.