SCROLL BAR problem with long list of plugins

[oneswitch]

Often if I have a profile with a long list of profiles, when I add new ones, I can't scroll down (nor resize the window) to see them.

The solution is normally to add them (invisibly) and then restart UCR. Or add a load of NOTES and get to them that way.

[evilC]

Yeah, I cannot work out why this is breaking.
I suspect that it is not UCR, but it is the GUI scrolling code in AutoHotkey (Which I co-wrote, so no blame-shifting here :P )
Unless I can work out what the problem is, I am afraid that this is unlikely to be fixed in the current iteration of UCR

[chrisfirefox]

If it helps, I can (hopefully) deduct what is happening, I don't want to offend, just pointing out what I observed: When adding elements (of various height I presume) to the list, the scroll list resizes to the full height of the current window instead of the full height of the (presumably) panel it currently resides in. That pushes the lower edge of the scrolllist out of sight and therefore some of the items too.

Hope it helps.

[evilC]

No offence mate, I wrote the UCR code, and I also wrote the code in AHK_H that handles scrollbars, so if there is a bug, it's 99% likely my own cock-up ;)
Can you find a sequence of actions (ie adding plugins, scrolling etc) that reliably reproduces it? That's always been my problem - if I cannot force it to reliably happen, I cannot check any potential fix to see if it worked.
Also, if it does not happen reliably given a sequence of actions, it may well be that it is timing related, not bad maths / using the wrong values.

[chrisfirefox]

I can do so every time, with always the same effect: I'm on Win10 64bit and I'm using UCR to merge my Thrustmaster 16000 HOTAS into one vJoy. So I have every Button with "Remapper Button to Button" and every Axis with "Remapper Axis to Axis" mapped to a vJoy output, that is roughly 40 Buttons and 7 Axis, resulting in a very long scrollbar. Testing this, I found that the most reliable way for reproduction is to resize the UCR window, either by maximize/restore or just dragging the windows lower right corner. Changing the profile fixes the problem.

When testing this right now I also experienced several seconds of lockup for my whole windows UI, seems like the recalculation of the scrolling window contents takes so long that the windows ui messaging queue locks up on UCR (which shouldn't happen at all given preemptive multitasking - not...). Happens with my long profile when first opening a dropdown (plugin selection), when first clicking a button in the "Remapper Button to Button" or "Remapper Axis to Axis" plugins. If you want this in a separate report, just let me know.

I also attached an image of how it looks like when it breaks.

[evilC]

Yeah, unfortunately debugging while doing a resize is very very tricky.
I know it can happen when you add a plugin, so ideally if we could reproduce by adding X plugin, adding Y plugin, problem occurs, then that would be ideal.
By the way, if all you want to do is a straight remap (ie you just need basic plugins such as axis -> axis, button -> button etc ) then you are probably better off with the new UCR

[chrisfirefox]

I tried and failed to reproduce it by adding/removing items, so sorry on that front. And new UCR doesn't work for me, like at all. Anyways, this UCR does what it is supposed to, and one can easily reset the out-of-bounds scroll area after a resize by changing profiles back an forth, so aside from the annoying multi-second-UI-delays, this works for me :).

[evilC]

If new UCR does not work for you, chances are the DLLs are blocked.
Save this as unblock.ps1 in your UCR folder, then run it as admin: Get-ChildItem -Path '.' -Recurse | Unblock-File

[chrisfirefox]

That did the trick, thanks! Even though I have to admit that "old" UCRs UI, with all its delays, feels more compact than the rewrite's. Anyways, sorry I couldn't help with this bug though.