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 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 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 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
> 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
> "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
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
* 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
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
--
===
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
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
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 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
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
14 matches
Mail list logo
