Kornelia Poenitz wrote:
> See attached.
Super!
Thanks, Alfredo
000
@@ -34,6 +34,7 @@
#include "FuncStatus.h"
#include "LColor.h"
#include "bufferview_funcs.h"
+#include "coordcache.h"
#include "cursor.h"
#include "debug.h"
#include "dispatchresult.h"
@@ -97,18 +98,46 @@ MathArray const &
On Mon, Apr 15, 2002 at 03:52:57PM +0200, Juergen Vigna wrote:
> I don't know about that you have to see it. Where do you get the absolute
> postions from?
The absolute positions are cached from the last drawing. That has been the
main source of mathed specific redrawing problems, so I'd be more
On 15-Apr-2002 Andre Poenitz wrote:
> On Mon, Apr 15, 2002 at 03:14:19PM +0200, Juergen Vigna wrote:
>> Well yes it works on Buffer change now, but the values are still wrong,
>> you just compensate them in the edit() call now!
>
> Aehm, since this 'fixes' this case now, should I commit it?
It
On 15-Apr-2002 Andre Poenitz wrote:
>> I try it with other words a math inset in the middle of a row (which say
>> starts at x position 200) will have as x position in the call to edit AND
>> insetButtonPress 0 if I press BEFORE the first character INSIDE the inset.
>
> Does this mean, mathed c
On Mon, Apr 15, 2002 at 03:14:19PM +0200, Juergen Vigna wrote:
> Well yes it works on Buffer change now, but the values are still wrong,
> you just compensate them in the edit() call now!
Aehm, since this 'fixes' this case now, should I commit it?
Andre'
--
Those who desire to give up Freedom
On Mon, Apr 15, 2002 at 03:14:19PM +0200, Juergen Vigna wrote:
> Well yes it works on Buffer change now, but the values are still wrong,
> you just compensate them in the edit() call now! Practically you would
> have to use the x/y code you use in ::insetButtonPress()! So if I get
> edit(bv, 0, 0,
On 15-Apr-2002 Andre Poenitz wrote:
>
> Could you check whether the attached patch makes a difference?
Well yes it works on Buffer change now, but the values are still wrong,
you just compensate them in the edit() call now! Practically you would
have to use the x/y code you use in ::insetButton
>lockInset(this))
+ lyxerr[Debug::MATHED] << "Cannot lock inset!!!" << endl;
+ delete mathcursor;
+ mathcursor = new MathCursor(this, front);
+ metrics(bv);
+ bv->updateInset(this, false);
}
@@ -191,8 +196,8 @@ void InsetForm
On 15-Apr-2002 Andre Poenitz wrote:
> Of course mathed has ignored the x and y parameters of edit(bv, x, y, ...)
> from the Beginning of the World.
>
> So these are important?
It seems so ;) Anyway I don't think you ignore them completely otherwise
you couldn't see if you entered from behind o
On Mon, Apr 15, 2002 at 12:48:31PM +0200, Juergen Vigna wrote:
> > I see. But if I simply subtract xo_, yo_, behaviour does not really change,
> > so I guess there is something else wrong.
>
> Well it's easy to test. If an outside program calls getCursorPos(bv, x, y)
>
On 15-Apr-2002 Andre Poenitz wrote:
> I see. But if I simply subtract xo_, yo_, behaviour does not really change,
> so I guess there is something else wrong.
Well it's easy to test. If an outside program calls getCursorPos(bv, x, y)
and then calls inset->edit(bv, x, y, 0) the cu
the 'or' part:
Currently, each inset stores the position where it got drawn last time
(in xo_, yo_) and getCursorPos returns this.
> You now return absolut position which is wrong.
I see. But if I simply subtract xo_, yo_, behaviour does not really change,
so I guess there is s
Andre',
the mathed insets are returning wrong values for this function. Please
head that the values should be relative to the inset position or inside
the inset they should be absolute to itself!
You now return absolut position which is wrong. Try to change buffer while
inside a mathed inset you
14 matches
Mail list logo
