Don't make inputs update on change

Try to set the scale of something to 0.5. You can’t do that without copy+pasting because Wick Editor will change it to 0.001.5 when you are done typing. The 0.001 comes from when you try to type 0 in, and Wick Editor clamps the value to 0.01, and the .5 comes after. I think inputs should only change when you lose focus or press ENTER.

3 Likes

I’ve run into kind of similar issues when naming clips. For example, if I have three buttons that I want to call “pick1”, “pick10”, and “pick100”, I could have a situation where I’m trying to type pick10, and before I can type the 0 at the end, it sees that I’ve typed “pick1” so far, and since that’s already the name of a clip, it automatically changes it to pick1_copy. I realize this could be avoided if I typed the names in a certain order to prevent this from happening, but it’d be nice if the autocorrect didn’t take affect until after you’ve stopped typing.

there used to be a really infuriating issue with commas being added in numbers. from what i remember, if you have a number like 1,000:

  • adding another number removes everything right of the comma
  • deleting one number deletes everything right of the comma

the problem you show is also a very annoying issue, but for me you can click out of the item and click back, then keep doing that until it works.

another suggestion to wick is to prioritize either the scale over the value or vice versa. since there are always good reasons to have it either way, the prioritized value for individual items should be the one that was changed last.

as of testing, i had a rectangle and shrunk the width to 0. it came back as 0.05 and the scale was 0.01 or something. i did it again and the value was 0 and the scale was something else, idk. i went back, and instead of scale being NaN (which it should be because width is 0) it still showed up as 1. there’s probably a hidden tiny decimal somewhere that always rounds up, thus never actually being 0. if you expand the scale enough, the rectangle will expand. (my strategy did not work)

if we prioritize size, we first have to completely ignore scale, regardless of if it has more than 3 decimals (i kinda reasoned that already). after the size is changed, the scale can be calculated and rounded. the scale here is kinda meaningless in exact size but since it may need 3+ decimals, it doesn’t screw up the actual size by increasing size until it works. to do scale, we just do the opposite of this.

1 Like

@pumpkinhead On a side note, I just remembered something that could fix your issue. If you want to set the scale of something to a number less than one, you can type the decimal first, without starting with zero. After you type the first number after the decimal, Wick automatically adds a zero in front of it, and it doesn’t cause the issue you mentioned.

Bleh, these inputs have always been a pain. I’ll take a look and see if there is an improvement that can be made for 1.19

1 Like