Ian Jackson wrote on Friday, September 30, 2005:
Hi, Thanks for the clear response. Unfortunately, I should definitely
have mentioned in the original post that I had already tried setting
break points. The meetConditions part is deliberately set
meetConditions = YES, just before the code is executed, and that's
what appears to be the case in the debugger. A break point in the
code that executes if the conditions are met
(addParticularSegmentToPath) does stop the program, so the code is
definitely being executed. It seems like, just being inside the if
statement causes some sort of problem.
I cannot imaging what. In all my years of experience with
compilers, I've never had any exhibit behavior that would make me
question the integrity of an if/else block. The only thing that
seems really odd to me is that you reassign the variable being
passed on each call to the statement:
- (NSBezierPath *)addSegmentToPath:(NSBezierPath *)aPath {
if (meetConditions) {
aPath = [self addParticularSegmentToPath:aPath];
}
return aPath;
I have no idea if this is all of your code or why you would choose
to do this. But it does beg the question of what would happen if
meetConditions was false and aPath didn't get reassigned, or if you
have a subtle syntax error in your code, of if some other call
didn't faithfully return the parameter you passed it such that
aPath suddently points to another object, or nothing at all. This
seems like a programming convention that's ripe for introducing bugs.
My only suggestion is to keep debugging. Walk through the each step
of your program as it calls addParticularSegmentToPath, and the
step through it when meetConditions is false and try to find out
what's different.
And you never really explain what "doesn't work" means, so we can
only offer broad suggestions on how to track it down. If I were a
betting man, I'd lay 10,000,000:1 odds that you've got a subtle
programming bug somewhere against the if statement of the compiler
being broken.
--
James Bucanek
