tmb@davinci.acc.Virginia.EDU (Thomas M. Breeden) (05/15/91)
May 15, 1991 I've got the DeadKeyConvert() example code (in RKM and AmigaMail) for reference, but want to use it in conjunction with my usual IDCMP support module and fear that I might have a problem. Normally, I use a separate task to read, copy, and immediately reply to all incoming IDCMP messages. The comment in AmigaMail that the iAddress field in the IntuiMessage that needs to go into the ieAddr field in the InputEvent for RawKeyConvert() is validf "until the IntuiMessage is replied" caught my attention. I take this to mean that running the DeadKeyConvert() code on the copy of the previously replied IntuiMessage will probably cause problems. Can anyone verify or deny this? The meaning of this iAddress field for RawKey messages is not at all clear from the doc ("magic" previous codes?). Can anyone explain what is going on? Thanks, Tom Breeden tmb@virginia.edu -->> Internet tmb@virginia -->> BITNET - Tom Breeden tmb@virginia.EDU -> Internet tmb@virginia -> BITNET
peter@cbmvax.commodore.com (Peter Cherna) (05/22/91)
In article <1991May15.122828.12061@murdoch.acc.Virginia.EDU> tmb@davinci.acc.Virginia.EDU (Thomas M. Breeden) writes: >I've got the DeadKeyConvert() example code (in RKM and AmigaMail) for >reference, but want to use it in conjunction with my usual IDCMP support >module and fear that I might have a problem. > >Normally, I use a separate task to read, copy, and immediately reply >to all incoming IDCMP messages. The comment in AmigaMail that the >iAddress field in the IntuiMessage that needs to go into the ieAddr >field in the InputEvent for RawKeyConvert() is validf "until the >IntuiMessage is replied" caught my attention. > >I take this to mean that running the DeadKeyConvert() code on the copy >of the previously replied IntuiMessage will probably cause problems. >Can anyone verify or deny this? That is correct. Replying the IntuiMessage before calling DeadKeyConvert() will cause problems. However, note that you copy *((APTR *)msg->IAddress) into the ievent.ie_position.ie_addr, which is an APTR, which is a 4-byte object. So it's acceptable to copy that away for RAWKEY events before replying them, then stuffing it into the input event for RawKeyConvert() after the reply. Something like (based on the RKM example) while (msg = GetMsg(...)) { if ( ( class = msg->Class ) == RAWKEY ) { /* This info must be extracted before the ReplyMsg() */ iaddr = *((APTR *)msg->IAddress); } /* msgcopy is an instance of IntuiMessage. We'll use * &msgcopy where we had used msg before. */ msgcopy = *msg; ReplyMsg( msg ); ... case RAWKEY: DoKeys( &msgcopy, iaddr ); ... Later, /* Modified to receive iaddr separately */ VOID DoKeys( struct IntuiMessage *msg, APTR iaddr ) { ... /* Modified to send iaddr separately */ numchars = DeadKeyConvert( msg, iaddr, &buffer[0], BUFSIZE, 0L ); ... } Later, /* Modified to receive iaddr separately */ LONG DeadKeyConvert( struct IntuiMessage *msg, APTR iaddr, UBYTE *kbuffer,... ) { ... /* Use iaddr fished out earlier, since the one in the message * we've been passed is invalid on account of the fact that * the message is already replied. */ ievent.ie_position.ie_addr = iaddr; ... } > >The meaning of this iAddress field for RawKey messages is not at all >clear from the doc ("magic" previous codes?). Can anyone explain what is >going on? The "magic" codes are the dead-key codes for the (up to 2) previous keystrokes, which RawKeyConvert() uses to do the proper conversion. >Thanks, > >Tom Breeden Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."