I had a similar problem when using the keyDownEvent to check if the field
had changed. I trapped the keyDownEvent and then tested
if(FldDirty(fieldP)). It wasn't on the first character. Why? Because I
was trapping the keyDownEvent before the field got it! So i did something
like this (from memory, so excuse any missing checks or logic):
case keyDownEvent:
handled = FldHandleEvent();
if(FldDirty(fieldP))
// do dirty stuff
break;
Maybe a couple of things for you to try here?
Kevin
__________________________
Kevin O'Keefe
The Windward Group
TEL: (408) 399-8577
FAX: (408) 395-9642
mailto:[EMAIL PROTECTED]
__________________________
> -----Original Message-----
> From: Dave Lippincott [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 16, 1999 8:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: dirty field not returning dirty
>
>
> Yup, its happening both times. Even if I use if
> (FldDirty(OurField)). The
> thing that really bothers me is the code works for the 2nd
> character entered
> in a field but not the first (and the debugger shows the
> dirty bit set after
> the first char is entered!)
>
> Maybe a better question is how do I detect the user has
> modified the field
> at all? I can't wait to exit the form to process the field,
> I need to do it
> after each character is entered and/or modified.
>
> D
> -----Original Message-----
> From: Kenneth Albanowski <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Sunday, May 16, 1999 9:32 PM
> Subject: Re: dirty field not returning dirty
>
>
> >On Thu, 13 May 1999, Dave Lippincott wrote:
> >
> >> My code does work for the second character entered but not
> the first.
> Any
> >> ideas?
> >>
> >> Here's a little part of the code:
> >> OurField = (FieldPtr) GetObjectPtr(MyField);
> >> if(OurField->attr.dirty == 1)
> >> {
> >> // Do something
> >> // This code only gets executed on the 2nd char
> entered in the field
> >> }
> >
> >Two comments, both unlikely to be helpful for you: if it's
> happening the
> >second time, but not the first, check to make sure the event
> flow actually
> >matches what you are expecting. Perhaps when the code
> executes the first
> >time, the dirty flag really hasn't been set yet. (If the debugger is
> >giving conflicting information, a more severe problem seems likely.)
> >
> >Secondly, in C you might want to avoid the "== 1" or "==
> true" test, and
> >instead rely on conditional testing. Remember that C accepts
> any non-zero
> >value as true, so you can say:
> >
> > if (FldDirty(OurField)) // instead of (FldDirty(OurField)==1)
> >
> >You can test for false by saying "== 0", or by prepending
> the ! operator.
> >
> >IMO, this syntax can be preferable as it will accept any
> non-zero value as
> >true, and will therefore be more reliable if functions (or the
> >compiler...) ever returns a value other then 1 to mean true.
> >
> >--
> >Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
> >
> >
> >
> >
>
>
