Correct. Don't do this. Your code will break in the future. That is why
these fields are hidden.
For scrolling, you can use the method to set the scroll position.
For the background, if the normal background image doesn't do what you want,
then implement your own background drawing. Clearing and re-setting the
background field is clearly relying on implementation details that can
change in future versions.
If there are specific features you find are missing, you can file feature
requests or (more likely to have a result) submit patches to add those
features. For the latter, though, keep in mind that we are very restrictive
on accepting changes to fundamental parts of the system like this.
On Mon, Apr 27, 2009 at 8:13 PM, Peter Carpenter <
peter.carpen...@skytechnologies.com> wrote:
> Hi Dianne,
>
>
>
> Thanks for replying.
>
>
>
> I want to create custom GUI components and access things like View.mScrollX
> which has no setFunction (to create a horizontally scrolling view), and
> mBGDrawable which does have a set function - but that does a whole heap of
> stuff I don’t want it to do.
>
>
>
> Essentially with the second option, I would like to have an image button
> using all of the standard background drawables (but hide only the default
> standard enabled state image). I can’t find API’s that let me do any of
> this cleanly. The only way I can currently find is to intercept the draw
> function and hide the background temporarily. It would be nicer to be able
> to either create my own StateListDrawable using the existing button
> background drawables (which are not public) or else have a removeState
> function in the StateListDrawable.
>
>
>
> So essentially you are saying I shouldn’t be doing this???
>
>
>
> Cheers,
>
>
> Peter.
>
>
> ------------------------------
>
> *From:* android-developers@googlegroups.com [mailto:
> android-develop...@googlegroups.com] *On Behalf Of *Dianne Hackborn
> *Sent:* Tuesday, 28 April 2009 1:02 PM
> *To:* android-developers@googlegroups.com
> *Subject:* [android-developers] Re: Compiling against a *REAL* android.jar
> in eclipse???
>
>
>
> Don't do that. If you aren't writing an app but system code, use the
> platform build system.
>
> On Mon, Apr 27, 2009 at 7:29 PM, Peter Carpenter <
> peter.carpen...@skytechnologies.com> wrote:
>
> Hello everyone,
>
>
>
> I’d like to be able to extend classes like View and still have access to
> the protected member variables.
>
> Under the standard SDK’s, android.jar is only a stub and so access to the
> protected member variables is not found. (And also all classes tagged as
> {hide} are hidden)
>
>
> Does anyone know of an easy way to get around/FIX this without going linux?
>
>
>
> Cheers,
>
>
>
> Peter.
>
>
>
>
>
>
>
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
>
>
>
> >
>
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
