[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [StrongED] Run icon in Obeyfile crashing with error
In message <1e97b80452.pittdj+@xxxxxxxxxxx>
David Pitt <pittdj@xxxxxxxxxxxx> wrote:
> In message <4431b50452.fjgraute@xxxxxxxxx>
> Fred Graute <fjgraute@xxxxxxxxx> wrote:
>
>
> [snip]
>
> > I haven't examined this fully yet but it seems that clicking on Toolbar
> > icons can go wrong when there's no StrongED view that has input focus.
>
> > Can you, or David, confirm this?
>
> Yes that does it, everytime, SE 4.69a4.
>
> Well spotted.
Thanks David for the confirmation, and for the register dump which was
most useful.
The code is doing something really strange. It tries to work out if
caret is in a block or not so that it can set the scope (block or text).
However it blindly assumes that there is a view with the caret as you
can see below.
ORR R5,R5,#key_block ; assume we're in a block
LDR R14,[R12,#caretview%] ; ptr -> view with caret, -1 if none
LDR R1,[R14,#caretadr%] ; oops, bombs out when no caret view
LDR R2,[R12,#blockstart%] ; ptr -> start of block, -1 if none
LDR R3,[R12,#blockend%] ; ptr -> end of block, -1 if none
CMP R1,R2 ; caret adr < start of block?
BIClt R5,R5,#key_block ; if so, caret can't be in block
CMP R1,R3 ; caret adr > end of block?
BICgt R5,R5,#key_block ; if so, caret can't be in block
It's strange that this didn't cause problems earlier. I have a vague
memory that earlier ARMs did something special when reading from the
very top of memory. Can't remember the details though, does anyone
happen to know more?
For now I've put in a check for caret view being -1 to stop the abort.
It may be good to also check if the view the toolbar belongs to is the
same as the view with the input focus (if there is one). Some more
thinking required on this.
Cheers,
Fred.
--
StrongED developer
http://www.stronged.iconbar.com/
--
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx