Browse lookup problem

Kenneth Brody kenbrody at spamcop.net
Tue Jun 14 08:00:09 PDT 2011


Any update?

On 6/9/2011 4:08 PM, Kenneth Brody wrote:
> On 6/9/2011 3:52 PM, Richard Kreiss wrote:
> [...]
>>>> I will retest this on my test database and see what happens.  I will
>>>> then let you know.
>>>
>>> Well, what did you mean when you had previously said that you looked at
>>> ba/bb/bc in the debugger, and that they "appeared to be correct"?
>> [>]
>>
>> When I ran the debugger and hit<F>   and entered ba the value of ba is
>> applied in the program appeared as did the rest when tested.
>>
>> Now, the problem is these values may have been shortened as the value as
>> been set in auto processing.
>
> You said that someone added an array that changed the definitions of
> ba/bb/bc to (8,.2).  Given that, it's not possible that the values "may have
> been shortened".  Rather, given that you didn't put a number into the field,
> it would result in ".00", which is exactly what the browse window showed.
>
> You still haven't said what you meant by "appeared to be correct".  When you
> looked at it in the debugger, what did you see?
>
>> As you indicated, a message box or even a show statement would have pointed
>> the foreshortening of the field from its uncast version.
>>
>> As the kids today like to say, "my bad" (:
>>
>> When I get a chance, I will test this both way, in the debugger and with the
>> msgbox to see what actually happened.
>
> Given the change to (8,.2), I would expect "     .00" in both cases.
>
> And, given that you said the browse window showed three ".00" entries per
> line, that fits the expected results.

-- 
Kenneth Brody


More information about the Filepro-list mailing list