View Issue Details

IDProjectCategoryView StatusLast Update
0001055OpenMPTUser Interfacepublic2017-12-10 16:27
Reporterblimey Assigned ToSaga Musix  
Status resolvedResolutionfixed 
Platformx86OSWindowsOS Version10
Product VersionOpenMPT / libopenmpt 0.3.2/0.3.3 (upgrade first) 
Target VersionOpenMPT / libopenmpt 0.3.4 (upgrade first)Fixed in VersionOpenMPT / libopenmpt 0.3.4 (upgrade first) 
Summary0001055: Can't paste BPM info from Excel due to input validation

Usability problem: pasting a number from Excel into the "Initial Tempo" or "Loop Tempo" fields is rejected due to input validation.

Steps To Reproduce

Figure out the BPM in Excel - for me that's figuring out the BPM based on the sample frequency and length of sample
Copy the number from an Excel spreadsheet on to the Windows clipboard
Try paste the number into the "Initial Tempo" or "Loop Tempo" field
The validation message pops up:
Unacceptable Character
You can only type a number here

Additional Information

Can work around this by pasting the number into notepad and copying it to the clipboard buffer again, but it's inconvenient.
I think this is because Excel puts a a newline character in the clipboard buffer after the number. I think you could just trim the text from the clipboard buffer to address this.

TagsNo tags attached.
Has the bug occurred in previous versions?Yes
Tested code revision (in case you know it)


Saga Musix

Saga Musix

2017-11-08 23:28

administrator   ~0003322

I'm afraid that newlines are generally not accepted by Windows numeric input fields. However, that should apply to any numeric input fields, not just tempo fields. Since tempo fields allow for fractional inputs, they have a different validation but its newline rejection is just identical to normal integer inputs.



2017-11-11 18:28

reporter   ~0003341

If the newline could be rejected by trimming off whitespace, rather than completely rejecting the input that would be better IMHO.

Saga Musix

Saga Musix

2017-11-11 18:38

administrator   ~0003344

Well as I said, any kind of numeric input field in Windows will reject newlines, and if we wanted to work around that, we would have to change the behaviour of every single numeric input field in OpenMPT. Maybe it's actually not the newline but some invisible character close to the newline that is causing the rejection, though?

Saga Musix

Saga Musix

2017-11-18 18:08

administrator   ~0003353

Okay, I found that while newlines at the start of a pasted text are not acceptable in generic number edit fields, they are accepted at the end, which the decimal input field for tempo and various other things didn't like.
r9315 should avoid this issue, and can be downloaded from within the next few hours.

Issue History

Date Modified Username Field Change
2017-11-08 21:28 blimey New Issue
2017-11-08 23:28 Saga Musix Note Added: 0003322
2017-11-11 18:28 geoffswift Note Added: 0003341
2017-11-11 18:38 Saga Musix Note Added: 0003344
2017-11-18 18:07 Saga Musix Assigned To => Saga Musix
2017-11-18 18:07 Saga Musix Status new => assigned
2017-11-18 18:08 Saga Musix Target Version => OpenMPT / libopenmpt 0.3.4 (upgrade first)
2017-11-18 18:08 Saga Musix Note Added: 0003353
2017-11-18 18:11 Saga Musix Status assigned => feedback
2017-12-10 16:27 Saga Musix Status feedback => resolved
2017-12-10 16:27 Saga Musix Resolution open => fixed
2017-12-10 16:27 Saga Musix Fixed in Version => OpenMPT / libopenmpt 0.3.4 (upgrade first)