OWL NExt - Knowledge Base

[ Home | Contents | Search | Next | Previous | Up ]

Transfer TRadioButton values

Date: 11/30/99
Time: 1:14:49 AM

Q. I am so mad I spent half my day trying to find out why the transfer of data
would not work for my radio buttons.

Do I have to set the transfer buffer for each button. (its the only thing I
didn't try)

A. Actually, you don't need to set transfer for each individual control.
The transfer mechanism works fine if, like I said, you change the variable used in
your window transfer structure to represent the state of radio buttons and check boxes
from a "uint" (which on some machines is interpreted as 32 bits) to "uint16".
If you check the file "c:\bc5\experts\owl\xfrstate.spp" you'll notice that for
TRadioButton and TCheckBox, the script uses "uint" to represent the state of these 2 control types.
This works fine on a platform which interprets uint as 16 bits.
On any other platform, chaos results. The (supposedly) "well-known" fix is to simply
change uint to read uint16. (It took me nearly 3 months to discover this priceless info,
since it is not in the help files anywhere). This allows Class Expert to install variables with
the correct width. (It doesn't matter if your app is 32-bit, the OWL transfer mechanism still
expects these variables to be 16 bits wide.) If you do some digging, you'll discover that the
variables OWL uses for these 2 controls are defined as "machine-specific".
But, what that implies to me is that these variables would be able to
change size depending on the platform. That is not the case.
If these variables are anything but 16 bits wide, it will offset the entire transfer mechanism,
so that any controls (using transfer struct) instantiated after the radio buttons and check boxes
(such as combo boxes, which contain pointers to string arrays and so forth) will be trying to point
to unallocated memory areas, etc. What appears to be a problem with the transfer for these other
controls will be caused by incorrect variable sizes for the radio and checks.

Trust me, if you change them from uint (or whatever they are now) to uint16,
your transfer struct troubles will go away (as long as you stick to the rules, i.e.,
the order of variables in your transfer struct must match the order of instantiation, etc.)

Give it a try, you won't be sorry.

Mike

Last changed: July 14, 2001