On Jan 27, 2008, at 5:01 PM, Brian Stevens wrote: >> Specifically text and style handles or the FB get field handle >> that combines the style and text into a single bundle? > > Are you avoiding FB's dynamic arrays because of the comment in the > FB Reference that says "Dynamic arrays may not be used to > dimension an array of handles"? Don't blame you for that. It is a > clear message. However, I've used FB's dynamic array to store > allocated (i.e. NewPtr) pointers (record array ) with absolutely > no issues. I haven't tried storing handles with OS X. Since I > haven't looked at the dynamic array code in many months, I could be > all wet here, but something tells me that the comment in the > reference manual is either outdated or applies to a specific use. > FBtoC implementation of dynamic arrays is different from FB's but I > don't believe it would prevent you from storing handles. It is FB's > implementation I haven't reviewed in a while. That caveat in the Dynamic docs, while necessary, has caused more confusion than a congressional committee. What it refers to has nothing to do with the ability to store a handle in a dynamic array (it's just a 4-byte integer, so of course you can), but the ability of FB to treat the array element as a handle. In old FB, there were certain things you could do with handle arrays, to get direct access to the data in the handle block. I tried to recreate this for a demo, but failed. The point of the caveat, though, was that you could never do that with a dynamic array. You can certainly store handles in FB dynamic arrays, but you'll need to either transfer them into separate handle vars for use, or manually dereference them. I can't think of any reason the same wouldn't be true in FBtoC. HTH, e-e =J= a y "