strange input mark behavior

maybe other aspect of shift-x text problems
I have a text that spans some bars.
start input at the marked bar (rest).jpg
In the first jpg I marked the rest in another bar (must be unter the text),
where I want to start input with a doubleckick
(works wrong only with mouse, not with enter).

With the doubleclick there appear two input rasters, but the cursor for
note input appeares in the bar where the text starts, not
where I double clicked to start note input:
two input rasters and input marks, but valid input where text starts.jpg

It is correct behaviour that the rhythmic grid should appear both in the bar where the caret appears, and also in the bar where the mouse pointer appears, since you can input a note in that bar too. (I tend to work with the selection tool – the arrow in the note input toolbox – switched on, since I don’t want to input notes with the mouse, and maybe you would like to try that too?)

Hi Daniel, but I doubleclicked to the location where the mouse pointer appears, (I did not click left and move then the mousepointer two bars further)

  • so the caret should move to that position!

And it does so, if I take away the text.
With the text, it does not, but puts the caret to the start of the text, while I doubleclicked two bars further!

So there is something wrong. (And if I mark the rest and hit enter, the caret moves there - its a problem with a) text and b) mouse.

Does your text item have a load of carriage returns/newlines at the end of it? If so, then it will be extending into the staff, and when you double-click, you’re actually double-clicking on the text item (which is always considered to be rectangular for the purposes of hit-testing it for mouse clicks), and as such the caret appears at the rhythmic position of the item you double-clicked – in this case, the text item which is rhythmically attached two bars earlier.

Maybe this was the case… but in this case, if I unintentially doubleclicked on a text -
shouldn’t this open the text editor instead of starting note input?
(And indeed, this is what happens - )
I cannot reproduce the behaviour now, with the latest update, so mayby it was fixed
somehow together with the bug that made the text move vertically up and up in edit mode?