Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
What follows has to be const_cast<Buffer &>(buffer).dispatch().
No, I want rather to use the global dispatch method. So that would be:
+ lyx::dispatch(FuncRequest(LFUN_BUFFER_CHILD_OPEN,
MSVC chose this one automatically for me but I'll do the change
anyway. Thanks.
I also had to add:
extern void dispatch(FuncRequest const & action);
to get it to compile. This isn't declared in LyX.h for some reason.
That is in LyXFunc.h, I'll fix that too, thanks.
Now that it does compile, I can confirm that...it segfaults. What I
send up seeing is a billion calls to getMasterBuffer(). The problem
has to do with how parentname is being set. One of my child docs is
turning out to be its own parent. This is a consequence of the
"inconvenience" we were discussing before, namely, that the active
buffer is being reset on each call. If I break in
LyXFunc::loadLyXFilename(), I can see that the wrong buffer is being
set as parent.
I see. Now that I know all use cases, let me think a bit about it, I'll
try to come up with a clean solution during the week-end.
Maybe the only clean way is to remove loadLyXFile from LyXView and
BufferView altogether.
Thanks for the help and testing.
Abdel.
Here's what happens: Master includes Child1; open that, now Child1 is
active; the parent of Child1 is now set to Master. Master also
includes Child2; so we open that, and now it is active; the parent of
Child2 is set to Child1, since that is the active buffer; Child2
includes Child1; that's already open, but now we reset the parent of
Child1 to Child2. We now have a loop, since Child2 is Child1's parent
and conversely, and we crash in getMasterBuffer(). But even if we
didn't get that loop, the parentname would still be wrong.
However that gets sorted out, this:
newBuffer->setParentName(parentfilename);
should perhaps be done only if newBuffer doesn't already have a parent
set. So something like:
if (!newBuffer->params()->parentname) ...
Or maybe we want to reset the parent. This must be related to the
"multiple inclusion" issue someone mentioned a bit ago.
Richard
