FrmGetControlGroupSelection is a routine with an interesting history, which might cause problems for developers. The first oddity is that it returns an object _index_, but the corresponding FrmSetControlGroupSelection routine takes an object _ID_ for the controlID parameter. The second oddity is that prior to Palm OS 3.5, it returned a UInt8 for the object index, instead of a UInt16 like all of the other form routines. For this reason, you have to compare the result to frmNoSelectedControl (0xFF) when checking for a no-match case, versus frmNoSelectedControl (0xFFFF). The third oddity is that in Palm OS 3.5, the routine declaration was changed so that it now returns a UInt16 instead of a UInt8. Note, however, that the no-match result will still be returned as frmNoSelectedControl (0x00FF). This last change creates some interesting limitations when mixing older (pre-3.5) versus new versions of Palm OS and apps build with older vs. new versions of the SDK. 1. ROM version < 3.5 a. App built with SDK < 3.5 (routine declared as returning UInt8) This works OK except for grouped controls that have object index values > 254. Having a form with more than 254 objects is a bad idea anyway. b. App built with SDK >= 3.5 (routine declared as returning UInt16) If the form has less than 43 objects, then there's no problem. If the form has 43 objects or more, then there's no problem if the found control has an object index < 43. If the found control has an object index >= 43, the routine result will be invalid (high byte of UInt16 result will have non-zero garbage in it). If a selected control in the requested group isn't found (the no-match case), then the result will not be equal to frmNoSelectedControl (again, the high byte of the result will contain non-zero garbage), and thus you'll get a false-positive result (looks like a match case). 2. Rom version >= 3.5 a. App built with SDK < 3.5 (routine declared as returning UInt8) For the match case (selected control found in requested group), this works OK as long as the control's object index is less than 255. Again, a form with more than 254 objects is a bad thing. For the no-match case, this works OK. b. App built with SDK >= 3.5 (routine declared as returning UInt16) This works OK, except for the match case where the control's object index is 255, in which case the app will treat it as a no-match result (false-negative). Not a real problem. So what does it all mean? The only somewhat plausible problem is if you're running on pre-3.5 ROMs, you built your app with SDK 3.5 or later, and you've either got a form that contains grouped controls with object indices > 42, or you have anticipated situations in which FrmGetControlGroupSelection needs to return frmNoSelectedControl. In that case you might want to ignore the high byte of the routine result, by casting it back to a UInt8. -- Ken Ken Krugler TransPac Software, Inc. <http://www.transpac.com> +1 530-470-9200 -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
