Thanks Mark, I would have thought it better to use a build tool derived id but I can certainly see an argument against it.
Using a starting id of 1 certainly seems to resolve the issue though I'm not sure how much I trust the resolution. Kind of feels like there should be a way of requesting / reserving id's on the fly for dynamic allocations but will leave validation routines in place to make sure there are no unwanted consequences. Thanks again. On 6 Sep, 12:23, Mark Murphy <[email protected]> wrote: > On Tue, Sep 6, 2011 at 7:19 AM, slipp3ry <[email protected]> wrote: > > Hello Mark, thanks for looking at my problem. > > > Sorry it's not clear from the code, the first instance of the ID's is > > driven by > > > bLast.setId(R.id.base_button_arrangement_id); > > > A user defined id rather than build tool assigned Id's > > No, all IDs defined as R constants are tool-assigned values, since you > did not specify the number. A developer-defined value would be > something like: > > 1 > > or possibly even: > > 1337 > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > Android 3.1 Programming Books:http://commonsware.com/books -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
