Jump to content

Search the Community

Showing results for tags 'AFD-531'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests & Feedback
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 2 results

  1. Reproduce: Adjust e.g. stroke width by typing the value -> press escape to try to remove focus -> press e.g. "v" because you want to use that tool and curse because focus is still in the input field.
  2. OK, I'm hitting this bug (or UI gremlin) constantly. My example is for a stroke width, but it seems to apply to all numerical value fields (e.g. opacity). 1. select a stroke 2. click into the stroke width slider numerical field in the stroke panel 3. type to change the stroke width (any value) 4. hit 'enter' to commit the stroke width change 5. hit 'v' key to change the cursor to the move tool (or any other tool keyboard shortcut) RESULT: the stroke is 'zeroed' in the field by the tool keyboard shortcut press, the stroke width change is cancelled, and the stroke width is set to 0 and becomes invisible. EXPECTED: the width change is committed after the enter key is pressed, and the cursor is changed to the move tool by the subsequent 'v' keypress. The expected behaviour works if I substitute a tab keypress for the enter keypress above - I think it's reasonable to expect that the 'enter' key should commit the field change in the same way, right?
×