palettes no longer editable in custom workspace

• Nov 26, 2021 - 05:38

Has anyone else encountered this? If you have and know of a solution, it would be great if you could share! TIA.

BTW, using CTRL+SHIFT to drag an element from the score to a palette was glitchy IIRC even before the palettes seem to have somehow become read-only.


In reply to by underquark

Thanks for responding! Yes, instructions followed.

In attempting to add any score element to a palette, the wee plus sign that normally appears during the click-and-drag process no longer appears. The result is that the dotted red line that should extend from the element being dragged to a palette won't cross over from the score onto any palette at all. Though the palettes are nominally enabled for editing (and in the past have been edited easily and successfully), they have become functionally locked (read-only?) to being customized in this manner.

In reply to by stevebob

What version MuseScore? What OS?

When I Ctrl+Shift, then click and drag a score element, I initially see a red circle (cursor) with a line through it. I don't see the "wee plus sign" appear until the cursor is actually over the target palette. (I see no red line when using Ctrl+Shift drag.)
MuseScore 3.6.2, Windows 10.

In reply to by Jm6stringer

Same 3.6.2 and Windows 10 here. If I described the 'wee plus sign' incorrectly, it's because I can no longer see it and am relying on memory of how it worked back when it actually worked.

At the risk of redundancy, I cannot even get 'over the target palette' any longer. I am very surprised you see no red dotted line, as that's the one element in this process that has remained the same for me both when the functionality worked as intended and now that it does not.

In reply to by stevebob

So here I am holding down CTRL+SHIFT whilst I click-drag my fingering symbol. I am pretty certain that my Wee Plus Sign appeared in the past at the location of the red dot(s), in which event I was able to cross over from the score space to the palette space. That doesn't happen anymore with any palette in any workspace even though Enable Editing is clearly enabled.

palette problem.png
palette problem closeup.png

Attachment Size
palette problem.png 16.97 KB
palette problem closeup.png 11.01 KB

In reply to by stevebob

I've not used my recollection, but tested both scenarios out in the current 3.6.2 on Windows10. The red anchor line does not appear if you press ctrl+shift before starting to drag; in that case the "forbidden" mouse pointer appears until you drag to a place where you can drop (such as the palette).
If you don't press ctrl+shift, the red dotted anchor line is visible, but you can't drag onto the palette.

In reply to by jeetee

Thanks for your response! FWIW nor am I relying upon recollection. I just tried the scenario again, following your specific advice, and no dice. There's been no change since yesterday, or since a few months back actually when this functionality quit on me.

In reply to by cadiz1

Thanks ... and now my question shifts to something different: why does my Musescore ( on Windows 10) look different to yours? I can only get a bad red line when I Click+Drag, regardless of whether CTRL+SHIFT is held or not. I have no idea at this point what it looked like early this year when there was no problem. I customized palettes using this very method. The 'wee arrow' thing, on the other hand, may be a figment of my imagination.

In reply to by stevebob

"when I Click+Drag, regardless of whether CTRL+SHIFT is held or not. "
It's not click + Drag.
Again it's (two steps):
1) Push and held CTRL + SHIFT, then
2) Drag the symbol with mouse and drop in the palette (now you see the second part of the GIF, with the no-go sign, first, and the "+" that appears when you hover over the cell in the palette)

In reply to by cadiz1

With a normal drag (without CTRL+SHIFT held down) the red line connects the item that you are dragging to its current anchor point. Generally the anchor point will not change during that type of drag, the exception being when you drag a dynamic and its anchor point moves from note to note.

If CTRL+SHIFT is held down before the drag starts, there is no red line because the anchor point is no longer relevant. Holding CTRL+SHIFT down while dragging is only used to drag something to a pallet.

The red "circle/bar" attached to the pointer while doing the CTRL+SHIFT drag operation indicates that you have not yet moved the pointer to a point where dropping the dragged item will deposit it in a pallet. When you do reach that point the red "circle/bar" changes to a "+" to indicate the pointer is in a valid drop zone.

The same red "circle/bar" also appears when dragging an item from the pallet to the score (without SHIFT+CTRL) if the element you are dragging is not in an appropriate place, for example if you drag a bar line and try to place it on top of a time signature.

In reply to by cadiz1

I know how to drag, and I know how to do it when CTRL+SHIFT are held. I've used a mouse since Windows 3.1, and I can assure that I have - as I've said repeatedly now - customized palettes using the selfsame method we're talking about now.

My initial premise here was that a known functionality has disappeared, but not a single answer addresses that potentiality. I've done what we're describing before. Lots of times. It worked once, and it doesn't work now. I haven't made any changes to my MuseScore installation. I've done software troubleshooting, and I know you need to eliminate the obvious possibilities. Repeatedly reciting the steps isn't useful, and we're spinning our wheels if we continue to approach this as 'user must be doing it wrong'.

In reply to by stevebob

This is resolved, and my only remaining curiosity is why cadiz has the red circle in addition to the 'forbidden' thing. Turns out that I have nothing but the 'forbidden' sign, which led me to believe that nothing could be dragged full-stop. Apologies for wasting your time, and thank you for your help.

In reply to by underquark

I had this problem happen a lot. Not just when changing workspaces, but anytime a score had been open for a while. It would always be fixed by closing and reopening MuseScore, but I just managed to fix it by right-clicking on the palette, and toggled the "Enable editing" check box off and on again. It reminds me of how sometimes some notes in a score stop playing, and toggling their "Play" property off and on again fixes it.

Do you still have an unanswered question? Please log in first to post your question.