View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001324OpenMPTUser Interfacepublic2020-05-17 20:472020-05-18 20:19
Reportersincx Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.29.00.* (old testing) 
Summary0001324: Pattern position not maintained when switching between modules
Description

Demonstration: http://i.sincx.xyz/pattsw.gif

When scrolled down past a certain point (exact point seems to vary?) in a pattern, when switching to another module and back, the pattern view is scrolled up well past where it was prior to switching.

In older versions (I tested 1.27 and 1.28), it seems that MPT tries to roughly snap the bottom of the pattern to the bottom of the view. In 1.29, though, as can be seen in the GIF, it does not do that at all, and loads even farther up. I don't know if this is a relevant observation, or if it is mere coincidence.

Steps To Reproduce

Load two modules (ideally one having relatively long patterns, I tested with length 128); scroll far down in a pattern in one, then switch to the other module, and switch back.

TagsNo tags attached.
Has the bug occurred in previous versions?Sort of (see description)
Tested code revision (in case you know it)r12866

Activities

Saga Musix

Saga Musix

2020-05-18 20:07

administrator   ~0004332

Last edited: 2020-05-18 20:19

I left a note about this in the code: Switching between modules (when MDI childs are maximized) first (invisibly) resizes the MDI child to windowed size, then it goes back to maximized size. This is why the scroll size sometimes moves. This happens either in the Windows MDI handling code or in MFC, definitely not in our own code. I have not found a workaround for this yet and I'm not sure if it's possible to work around at all.
Saga Musix

Saga Musix

2020-05-18 20:14

administrator   ~0004333

The difference in behaviour you notice is that you were probably using different settings with 1.27 / 1.28 and the restored window size of MDI child windows was bigger than in your 1.29 configuration. If the restored size of the window is bigger, this bug is less likely to happen (because the scroll limits would be different).

Issue History

Date Modified Username Field Change
2020-05-17 20:47 sincx New Issue
2020-05-18 20:07 Saga Musix Note Added: 0004332
2020-05-18 20:14 Saga Musix Note Added: 0004333
2020-05-18 20:19 Saga Musix Note Edited: 0004332