[Geoff Bacon]

Hi Mike

For our weekly 2 hour session, I normally create a set list of about 25 songs.

When creating the list, I've typically started reusing a list from a year ago.
After deleting songs I don't want to play, I add extra songs, usually the newer ones, to bulk up this list
As I don't know the order the final list will be, I just add these to the bottom of the list.

Having enough songs, I position the new additions by tapping the left hand number of a song (near the bottom of the list) and type in a new position for it e.g. 3, 5, 7, 9... The keypad for the number overwrites the bottom of the setlist so I have to do a "back" to dismiss the keypad so I can see the other entries that were obscured.

As always there are ways of getting around this e.g. "back", choosing approximate position when adding songs, doing an "Edit" of the list, positioning last item first etc. However, I just find it very annoying because I always seem to need to do extra operations to do what I want.

The list can be scrolled underneath the keypad but the keypad still obscures the last few entries (my entries are 2 lines each).

Could the code be modified so that when the last item is visible on the screen before the keypad is displayed, the bottom of the list is scrolled up above the keypad?
This would handle most occurrences for me (although it could result in the item being moved off the top of the screen!)

I suspect a better solution would be to just allow the full list to be scrolled underneath the keypad so that the bottom entry appears above it. I could then scroll it once when the keypad first appears and leave it like that for the rest of the shuffling.

Cheers
Geoff

[Zubersoft]

About the only thing I can somewhat easily do is change the application configuration so that when the keyboard is displayed, it resizes the application so that everything appears above the keyboard. This might be preferred when in the group editor, but it is less desirable on the main library screen (as that shares the same configuration as the song display). I can make these changes and we can see if it works better for you. If you want to test out the changes today, let me know

Mike

[Geoff Bacon]

Hi Mike

I'd be more than happy to try out the changes

Geoff

[Zubersoft]

I think I've got it all taken care of. I had to manually handle the keyboard being displayed, and I just shrink down the available height so that you can scroll to the end of any of the lists. You can check out the changes in v3.7.6. Thanks for the offer to help test though!

Mike

[Geoff Bacon]

Thanks for doing this Mike but it is not quite right

After the upgrade, I restarted MSP.
The list does allow me to scroll/view the last entry but there is a big horizontal black band (just under an inch high) between the keypad and the bottom of the list (waste of screen space).

Experimenting on a 27 entry list, I selected the left hand number of an entry and retyped the same number; after a couple of other tests, I notice that the keypad number buttons, as well as showing the normal number, had small grey numbers in their top right corner e.g.  1 not affected, 2 had 1, 3 had 2, 4 had 3 etc 9 blank, 0 has 8
I've never seen this before and I can't reproduce it (probably nothing to do with MSP but strange)

Having pressed the back button and tried another couple of times, I find that the black band no longer appears. - I also can't scroll to the bottom of the list (processing entry 10, the keypad obscures entries 24 to 27 when the list is scrolled

Restarted MSP, moving item 10 to 11 doesn't allow me to scroll/see items 24 to 27. There is no black band

Moving 22 to 23  doesn't allow me to scroll/see items 24 to 27
I have managed to redisplay the small numbers on the keypad - they disappear if one selects another list entry number. ie you can probably ignore this.

Restarted MSP processing a 24 entry list
Trying to relocate item 8, the black band appears between keypad and list - I can scroll to last entry (24)
Black band continues to appear when repeating the operation on other items 

Just noticed after playing around, the 17th entry had a small 8 after the keypad disappeared  (the other numbers looked ok).
I think this is because I pressed back without doing a Done first

Backing out of the Set list and redisplaying it, the numbers are restored to normal size.
But no black band when I attempt to relocate items and bottom of list obscured by keypad.


I hope this gives you enough to work with.

Geoff

[Zubersoft]

I'll take a look at it, but there is one limitation with the current approach I'm taking - I'm not given information about the size of the virtual keyboard. So right now, I'm just limiting the height of the lists based on a fixed percentage of the screen (and a different percentage is used depending on the device size category and whether you are in landscape vs portrait). So this may be related to the black band you said you saw - the virtual keyboard you are testing with may have a different height than the one I'm testing with. I don't have a good solution right now that can handle any keyboard the user can install because the Android framework does not give me a way to easily identify the size of the virtual keyboard. I also can't utilize the automatic resizing unless I disable fullscreen mode in the group editor, meaning the status bar will be shown at the top of the screen, wasting some screen space. This is another limitation in Google's framework. With my testing, I never saw any unusual behavior like you described though - I could always scroll to the end of the list and there were no visual oddities. I did not test moving entries between different positions though - I can try that out to see if it makes a difference.

I may ultimately decide to just stop using fullscreen mode while editing setlists so I can utilize the automatic screen resizing. That would resolve all these issues at the expense of the wasted screen space due to the status bar at the top.

Mike

[Geoff Bacon]

Thanks Mike

[Geoff Bacon]

Just noticed that editing a setlist displays the keypad and then immediately hides it

I don't remember this before this update

Geoff

[Zubersoft]

I didn't change any code related to whether the keyboard should be shown when the setlist editor is first entered, but it's possible the new code to resize the lists is slowing down the UI enough on your tablet that it's making the keyboard collapse more visible.

Mike

[Geoff Bacon]

Thanks for the reply

Still strange though as I wouldn't have expected it to show unless the code told it to

Geoff

[Zubersoft]

I fixed the issue with the keyboard being temporarily displayed. I have also implemented some fixes because if you have the keyboard up while editing the index of an entry and you then scroll the list, it was causing issues when the entry was reused lower in the list. The keyboard is now automatically collapsed and the editing canceled if you scroll the list while actively editing the index of one of the entries.

After testing on multiple devices, I was able to reproduce some of what you described. So I believe my latest fixes should fix the issues you were seeing with not being able to access the entries at the bottom of the list.

Thanks,
Mike

[Geoff Bacon]

Thanks Mike

I'll wait for the update to appear on play store and let you know how it goes

Geoff

[Geoff Bacon]

Hi Mike

I've checked out 3.7.7 and I'm afraid there are still problems.

Working with a 23 song setlist

Aiming to relocate song 3 by tapping it's number and entering a new position
Displaying a Setlist (not Editing)
Tap 3, keypad appears
Scroll list downward (to see where the song should go); the keypad disappears and one is shown a full screen of song entries
Similar effect if one selects song 21 and scrolls up  (at least it is consistent!)

Seems similar if editing a setlist

Moving 19 to 1; wanting to process 20 to 23 (without hiding/reshowing keypad)
Displaying a Setlist (not Editing)
Tap 19, enter 1, DONE
One now can't scroll the bottom entries into view (they are obscured by the keypad)
Actually,  just tapping 16 doesn't let one see 20 to 23 (which are hidden by the keypad)

Editing a setlist; tapping 19 does let you scroll to get the bottom of the list showing above the keypad. However, scrolling back up makes the keypad disappear as soon as 18 goes behind it.

This is obviously not a show shopper as I can use the scrolling arrows on the edit screen and/or perform a back operation to hide the keypad to allow access to the hidden items.

Cheers
Geoff

[Zubersoft]

Geoff,

The first thing you described is not a bug - it's what has to happen now. The problem before is that, if you are editing a number and you scroll down, the list reuses rows, so it would reuse the row that was actively being edited, but that row is in a weird state because the edit control was displayed and actively had focus. So the framework just does not support that at all. You have to know what index you want to move the entry to before entering it. Otherwise you can use the standard drop and drop functionality.

As far as the second issue, I tested on four different devices with four different virtual keyboards, and on each of them, I could always scroll to the bottom of the list with the keyboard up. I have no idea why it's not working for you, or which virtual keyboard you currently have active. I can't test for every possible keyboard out there and across every Android version. I'm relying on a hack of sorts to figure out the height of the keyboard (because Google does not provide a way to access this directly), so it's possible it won't work with every keyboard and/or OS version. I did test on a Samsung Note Pro 12.2 running Android 5.0, a Google Nexus 7 running Android 6, a Samsung Tab S4 running Android 10 and a Samsung S8 Ultra running Android 13. So I covered a fairly big range with that. It may help to see a video of how it appears on your device. 

Thanks,
Mike

[Geoff Bacon]

Thanks for the info Mike

Still a bit surprised as I'm sure that, on a windows system (I know this is android), one can still enter data in a focused non-visible field (I know you can't focus a hidden control but I thought the focus remained if a focused control was pushed out of sight or something appeared above it). 
I could be wrong!

I'm sending you a poor quality video (issues with file sizes and hand held phone) via WeTransfer.
In it, I'm showing that when I select item 19 I can't scroll at all to see the bottom entries.
However, when editing the setlist, doing the same operation, I can scroll to the bottom - although still limited by the restriction that the selected number has to stay in view.

Apart from the inconsistency in this behaviour, it sounds as though there isn't much you can do about it

Cheers
Geoff