Thanks for all the help! I've used Aarons way with the custom Event and it works wonderful. It also seems like the best way of solving it + i got the chance to learn about custom events, a knowledge one cannot be without in an eventdriven environment!
/Tony Malinaric "Aaron Ardiri" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > > field = FldGetObjectPtr(...); > > > > Calling FldHandleEvent yourself seems ugly to me. How do you know which, > > if any, field is active, and hence should receive the event? (I think you > > elided the interesting part in that elipsis! :-)) You might get away with > > > > if (FrmGetFocus () != noFocus && > > FrmGetObjectType (FrmGetFocus ()) == frmFieldObj) > > FldHandleEvent (...); > > this is tedious, yes.. > > > but it seems like a lot of trouble. I would think it's easier to let > > your usual SysHandleEvent/.../FrmDispatchEvent event loop take care of > > it and remember to do extra processing for keyDownEvents, with a custom > > event as Aaron suggested, or hopefully something like the following > > would get the timing right: > > > > EvtGetEvent (&e, ...); > > bool need_to_poll = (e->eType == keyDownEvent); > > SysHandleEvent ... || MenuHandleEvent ... || > > my_handle_event ... || FrmDispatchEvent ...; > > if (need_to_poll) { > > if (FldDirty (myfield1)) ...; > > if (FldDirty (myfield2)) ...; > > ... > > } > > eww... chew processor time :)) hehe.. > > posting your custom event is actually the most effective way.. it > is clean, and does not do any unecessary polling.. the event you > add is next on the queue.. just let it take its path.. > > cheers > > // az > [EMAIL PROTECTED] > http://www.ardiri.com/ <--- free games! > +46 70 656 1143 > > > -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
