On 06-Dec-2001 Allan Rae wrote:
> The use of the_locking_inset there seems haphazard at best. Some
> places seem to clear the_locking_inset after an unlock call while
> others don't.
Well sometimes I think you should sleep a bit more before looking at code ;)
You look at functions and don't see the obvious #:O) (a pitty you didn't
write this one on Friday I could think of a really amusing exchange of
emails ;)
> Code like:
> if (the_locking_inset) {
> unlockInsetInInset(bv, the_locking_inset);
> the_locking_inset = 0;
> }
Ok you're right here the above can safely be change to only
unlockInsetInInset(bv, the_locking_inset);
> seems to me to be equivalent to:
>
> unlockInsetInInset(bv, the_locking_inset);
> the_locking_inset = 0;
It is indeed!
> and could be written as:
>
> if (unlockInsetInInset(bv, the_locking_inset)) {
> the_locking_inset = 0;
> }
Nope the if is not neccessary, but yes if you like you could write it as
that too ;)
> but that isn't really any faster or better but might expose other
> bugs.
Why? The code in unlockInsetInInset() is quite clear
if (!the_locking_inset) return false;
Tis will just do nothing and the_locking_inset anyway is already 0,
so we don't have to set it to 0 again, isn't it?
> unlockInsetInInset() will do the check for the_locking_inset. The
> second line unconditionally resets the_locking_inset while
> unlockInsetInset() only resets it if this insets inset is the locking
> inset. The return value of unlockInsetInInset() tells whether it
> found a locking inset further down in the nested inset structure.
#:O)
Allan if I call unlockInsetInInset with inset==the_locking_inset why should
I check it. Obviously you're right with the setting to 0 the_locking_inset
it is not needed because of:
if (the_locking_inset == inset) {
the_locking_inset->insetUnlock(bv);
the_locking_inset = 0;
...
}
> Is there a plan to use the return value at anytime or should the
> following lines also reset the_locking_inset unconditionally like all
> the other instances in insettabular.C?
We don't need to use the returnvalue as it is irrelevant INSIDE THIS
insettabular, but unlockInsetInInset() is also called from the outside
world and there the returnvalue IS important!
> There appear as though there may be a few places where
> InsetText::the_locking_inset isn't cleared after an unlock attempt but
??? We don't have a InsetText::the_locking_inset!!!
> Maybe I'm misunderstanding something. If an inner inset is locked and
> I unlock it should the outer inset also be unlocked?
No, why should it! But if the outer inset is unlocked we have to descent
the tree and unlock ALL inner insets.
Hope this helps you a bit to find some good sleep tonight #:O) otherwise
have some of the really nice beers you produce there in Australia the also
help to have a good sleep ;)
Greets,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I have defined the hundred per cent American as ninety-nine per cent an idiot.
-- George Bernard Shaw
