Characters flow out the line if wrapmode is nowrap

[hwsguy]

When the texteditor gadget has MUIV_TextEditor_WrapMode_NoWrap for wrapmode and moving the cursor to the right or left border make the content scroll one character the line does flow out the text area.

As the image shown:
https://s5.postimg.org/xwayj5xnb/textcraft.jpg

[tboeckel]

Is there any easy way to reproduce this issue? I mean without having to use Hollywood? A simple example in C perhaps?
Right now I am not able to reproduce the issue myself. On my setup everything is done right, the text is scrolled as expected without being drawn across the object's frame.

[tboeckel]

Any hint for me?

[alpyre]

I am quite positive that this bug is because of an incompatibility with the layers.library on that system.
I remember seeing a similar issue on a Cybervision display (BVision actually) as I was testing the feature. It was fixed after updating the layers.library.

I suppose the culprit is this line:
mcc/PrintLineWithStyles.c

357    if(doublebuffer == FALSE)
358      AddClipping(data);

If the layer allocation (for the doublebuffering rastport) fails for some reason, you still have a doublebuffer rastport but a non layered one. So the above line decides not to AddClipping().

I hope this is a clue.

[tboeckel]

Not exactly. The "doublebuffer" variable is a parameter passed to the PrintLine() function. Hence the calling function decides whether to use double buffering or not. But you are right, if installing the clipping region fails the rendering is done to the double buffered RastPort, but without clipping. And this perfecly explains the misbehaviour.
But the big question now is: why does this happen at all? The clipping region is installed by calling MUI_AddClipping() in a wrapper function which ensures that MUI_AddClipping() is called once only. The accompanying function RemClipping() is always called pairwise, so there cannot happen anything bad either.

Which version of layers.library are talking here about exactly? I am using layers.library 45.22 (3.10.2014), which is not even the latest version (http://aminet.net/util/sys/layers.lha).

[alpyre]

Hmm. I went through the code once again and I think we both are wrong.

You're right about doublebuffer variable but, when PrintLine() caller decides to not use doublebuffering, the code then uses data->copyrp (which should be the objects rastport) with MUI_AddClipping() (not the other way around as you've stated).

And let's assume doublerp failed at initialization because of layers.library, then data->doublerp should be NULL and PrintLine() should again always fallback to use data->copyrp with MUI_AddClipping() (that's where I was wrong).

So whenever data->doublerp is not NULL (and PrintLine() is called with doublebuffer), such a behaviour can never occur. Because we always blit from the 0,0 coordinates of doublerp. It seems not possible to me.

So somethings must be going wrong in MUI_AddClipping() on that system. It maybe is again a layers.library issue if MUI_AddClipping() is depending on it.

[tboeckel]

Sorry for the long delay.
Can you easily reproduce this issue? If yes, then I can provide special versions of TextEditor.mcc and muimaster.library (MUI5) for AmigaOS3/4 to check whether MUI_AddClipping() and MUI_RemClipping() are working as expected in that case.
Otherwise I don't know how to fix this issue, because I am not able to reproduce it right now.

[tboeckel]

Bump!