Dear Developers
>From a user who's having soem trouble writing a report on my machine running
Lyx1.1.6fix1...
> What I am trying to do is append a column to an exisitng table. It crashes
> either ehile I am entering data into the new column or saving for the
> file. As for repeatable - it's done
in trunk
1. select range of cells with mouse:
lyx.exe!lyx::support::abort() Line 25 + 0x8 bytes C++
lyx.exe!boost::assertion_failed(const char * expr=0x00e95730, const char *
function=0x00e956e4, const char * file=0x00e956c4, long line=1110) Line 57 C++
lyx.exe!lyx::TextMetrics::getPitNe
Leuven, E. wrote:
> in trunk
>
> 1. select range of cells with mouse:
>
> 2. select range of cells with keyboard:
Try again, should be fixed now.
A/
OK, I've found the bloody source of the tabular crash. I don't know what
this resetPos() method is for but it should be used carefully.
Will commit soon if there's no objection.
Abdel.
Index: insettabular.C
===
--- insettabular.C
On Fri, 2006-10-20 at 16:30 +0200, Abdelrazak Younes wrote:
> OK, I've found the bloody source of the tabular crash. I don't know what
> this resetPos() method is for but it should be used carefully.
>
> Will commit soon if there's no objection.
>
> Abdel.
Don't you feel that you *ought* to und
Martin Vermeer wrote:
On Fri, 2006-10-20 at 16:30 +0200, Abdelrazak Younes wrote:
OK, I've found the bloody source of the tabular crash. I don't know what
this resetPos() method is for but it should be used carefully.
Will commit soon if there's no objection.
Abdel.
Don't you feel that you
Abdelrazak Younes wrote:
OK, I've found the bloody source of the tabular crash. I don't know what
this resetPos() method is for but it should be used carefully.
Here's an alternate patch. Which one do you prefer?
Martin, can I call this one a "fix"? :-)
Abdel.
Index: coordcache.h
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> OK, I've found the bloody source of the tabular crash. I don't know what
>> this resetPos() method is for but it should be used carefully.
>
> Here's an alternate patch. Which one do you prefer?
The other one. It makes clear that there is a
Georg Baum wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
OK, I've found the bloody source of the tabular crash. I don't know what
this resetPos() method is for but it should be used carefully.
Here's an alternate patch. Which one do you prefer?
The other one. It makes clear that
Georg Baum wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
OK, I've found the bloody source of the tabular crash. I don't know what
this resetPos() method is for but it should be used carefully.
Here's an alternate patch. Which one do you prefer?
The other one. It makes clear that
Abdelrazak Younes wrote:
> Nobody knows what this resetPos() is for?
I had a look at the code, and I believe that it is for horizontal
"scrolling": If you have a table that is wider than the screen and you go
to a cell that is at the right edge then, if you are lucky, the table is
shifted to the
Georg Baum wrote:
Abdelrazak Younes wrote:
Nobody knows what this resetPos() is for?
I had a look at the code, and I believe that it is for horizontal
"scrolling": If you have a table that is wider than the screen and you go
to a cell that is at the right edge then, if you are lucky, the tabl
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
Nobody knows what this resetPos() is for?
I had a look at the code, and I believe that it is for horizontal
"scrolling": If you have a table that is wider than the screen and you go
to a cell that is at the right edge then,
On Fri, Oct 20, 2006 at 05:08:24PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> >OK, I've found the bloody source of the tabular crash. I don't know what
> >this resetPos() method is for but it should be used carefully.
>
> Here's an alternate patch. Which one do you prefer?
>
>
Georg Baum wrote:
> I had a look at the code, and I believe that it is for horizontal
> "scrolling": If you have a table that is wider than the screen and you go
> to a cell that is at the right edge then, if you are lucky, the table is
> shifted to the left so that you can edit the cell and even g
Juergen Spitzmueller wrote:
> how about a horizontal scrollbar in such cases?
Yes: http://bugzilla.lyx.org/show_bug.cgi?id=1083
Georg
Well, I spent some fun time on this over the weekend ...
I now have it narrowed down to a file, and I'm becoming more convinced it *is* a
compiler
bug.
1) compiling tabular.C w/o -O "fixes" the problem
2) in tabular.C::operator=, line 121 :
121 cell_info = lt.cell_info;
In the c
On 09-Apr-2001 John Levon wrote:
> Since the line is un-necessary, we could "fix" this by not doing it in the Clone()
> case. But of
> course that isn't a proper fix (and we have a duty to tell gcc if it's reproducable
> with current
> gcc CVS ...)
>
> I'm really stuck now at what to do, I have
On Mon, 9 Apr 2001, Juergen Vigna wrote:
>
> On 09-Apr-2001 John Levon wrote:
>
> > Since the line is un-necessary, we could "fix" this by not doing it in the Clone()
> > case. But of
> > course that isn't a proper fix (and we have a duty to tell gcc if it's reproducable
> > with current
> > gc
On Mon, Apr 09, 2001 at 03:31:19PM +0200, Juergen Vigna wrote:
> Well I couldn't as IMO I'm more illiterate on STL (in general) the you :)
>
> But there are general problems in this type of stuff. F.ex. you can have a
> look at the AppendRow calls in tabular.C. You see that I do explicitely
> ins
Hi,
please read the statement concerning gcc 2.96 at gcc.gnu.org and you will see
they are definitely not be willing to have a look at the problem. However, if
the bug also occurs with gcc-3.0-cvs, they should know about it, of course.
Michael
--
===
* Michael Schmitt <[EMAIL PROTECTED]> [2001-04-09 19:14] schrieb:
> Hi,
>
> please read the statement concerning gcc 2.96 at gcc.gnu.org and you will see
> they are definitely not be willing to have a look at the problem. However, if
> the bug also occurs with gcc-3.0-cvs, they should know about
On 09-Apr-2001 Dekel Tsur wrote:
> I had no problem when I enabled the STL code in AppendRow.
> Do you have a problem when you compile without optimization ?
> Do we want to support buggy compilers ?
>
>
> BTW you can use
> cell_info.insert(cit, vector(columns_,));
> instead of
> cell_info
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> I also had a thought about the memory footprint for
Juergen> insettabular and the only possible solution I came up with to
Juergen> minimize it is to store the data inside a single paragraph as
Juergen> we did before. But do we
> I also had a thought about the memory footprint for insettabular and the
> only possible solution I came up with to minimize it is to store the data
> inside a single paragraph as we did before. But do we really want to do
this.
Jürgen,
why not create a super class to do just this. TabularMemo
On 10-Apr-2001 Angus Leeming wrote:
> Do you really think that this is necessary? Admittedly, it's inconsistent to
> have two different types of dialog (your's and all the others!), but your
> popup is quite intuitive to use. On the other hand, having an Apply button
> would mean minimise red
On Tue, 10 Apr 2001, Angus Leeming wrote:
> Easy! Create a temporary params struct which is changed by the dialog. On
> apply(), compare the contents of the struct to those of the inset.params().
> Only update the changes.
>
> Do you really think that this is necessary? Admittedly, it's incons
On 10-Apr-2001 John Levon wrote:
> I don't think it's worth it. A real fix of the tabular UI problems requires
> something like the grey excel-style "handles" I mentioned earlier ...
Well not really the handles may be usefull for selecting whole columns or
rows, and also as visual feedback, but
On Wed, 11 Apr 2001, Juergen Vigna wrote:
>
> On 10-Apr-2001 John Levon wrote:
>
> > I don't think it's worth it. A real fix of the tabular UI problems requires
> > something like the grey excel-style "handles" I mentioned earlier ...
>
> Well not really the handles may be usefull for selectin
On 09-Apr-2001 John Levon wrote
> I was hoping you were going to tell me I'm an idiot who knows nothing about how
> the STL vector works :/
Well I couldn't as IMO I'm more illiterate on STL (in general) the you :)
But there are general problems in this type of stuff. F.ex. you can have a
look
30 matches
Mail list logo
