Any changes made to snap / the way the vcb entered values are processed in the last update(s)?

Recently updated to 21.1.

I just noticed in LayOut when copying an object using (cntr) + (shift) and immediately type a value to set the accurate offset, half of the time the value displayed in the vcb is slightly different to the value I just entered.

For instance;

  1. I draw a line
  2. I hold cntr + start moving
    3.I add shift to constrain to an axis
  3. I release both and type a value say 100
  4. the vcb displays 98,9mm;0,0mm

This even happens when both grid snap and object snap are disabled.
Also happens with the default templates.

I hope anyone can reproduce this. Suggestions?

Something has changed the way (shift) is processed on Windows I suspect.

I also noticed after the last update, when editing text in Layout;

  • type something so you get multiple lines
  • set the cursor at the end of the second line
  • press shift + arrow up to select the last text line + a few letters on the first line
  • now press left arrow. Instead of expanding the selection on the first text line, it removes selected text from the end of the last line…!!! This is totally against any normal behavior in any text editor I know

do you mean this…
( I’m on Windows )

move_01

yes I mean that and more than half of the time it fails for me.
See here:
layoutVCB
layoutTxt

I’m getting this too

Also something curious - some text boxes that are in lowercase, when I enter them to edit, the edit display is all uppercase and when I finish editing it reverts back to lowercase :thinking:

@colin, could take a look at this and see if you can repro?

If you mean the first issue, drag, shift to lock axis, let go, type a number…

Yes, I see it go wrong, and I think I know what is happening. The same behavior happens in 2020, and most likely all versions of LayOut. It may even be intentional behavior.

I’ll try describing it, rather than show a screen recording that I would then have to explain. Try this:

  1. You’re about to move an object, say a square, 100 to the right. Put something else as a target to aim for, that is 200 to the right and 200 down from the square.

  2. Click in the lower right area of the square, and start your drag to the right. Hold down shift to lock the movement to horizontal.

  3. Mouse towards your target object, trying not to switch the locking to vertical. Let go of the mouse button and shift key.

  4. Type 100 Enter.

The object will show as having moved 70.71 instead of 100. It has moved this amount because it takes the direction of the cursor, and makes the object move 100 in that direction. Asking for 100 at 45 degrees is the same as requesting 70.71 horizontally.

Try that in any LayOut, I’m sure it will behave the same. The work around to the issue is to type 100,0 instead of 100. Or, as you shift-drag to the right, keep the cursor level with the start drag point.

2 Likes

Ah, now I understand it. That has confused me too some time, but usually I’m on axis and get the desired result.

For the record this would be “100; 0” in continental Europe and Quebec among some other places.

For this problem, I see that too. The first shift-left arrow will take the selection from the beginning of the first selected word, to then include the space before the first selected word. That doesn’t happen for you because you were selected on the second letter of the word.

After that preceding space is selected, the next shift-left arrow does start to remove letters from the end of the selection. That doesn’t happen in 2020.

@kath or @trent should take a look at that.

Hi all we are aware and are working on the fix for the Text selection issue using the left arrow to select.

@paul.mcalenan I have not been able to repro this issue though. Do you see this with standard fronts or is this a custom font?

Trent

1 Like

@colin Thanks for the replies. I never noticed this translation problem before but its there in 2020 I see as well.Will add the second coordinate in the vcb from now on as well (100;0).

I use the Lexend font Trent.

It’s infrequent and seemingly random so I wouldn’t be able to test the issue with another font unless I started with another font on a project.

I’ll monitor and report back.