[11.00b] Wrong dropdown menu widths in Multi-Rename Tool

[Flint]

I. Plus menu too narrow

1. Open Multi-Rename Tool.
2. Click the [#] button to see the range options menu.
3. Close this menu, and click the [+] button for the main expressions menu.
4. The menu is very narrow and cannot fit all the descriptions.
Screenshot: http://flint-inc.ru/Temp/tcbeta1100/tc11-mrt-narrow-menu.png

II. Range menu too wide.

1. Open Multi-Rename Tool.
2. Click the [+] button to see the main expressions menu.
3. Close this menu, and click the [#] button for the range options menu. (that is, the reverse to what was in the previous scenario)
4. The menu is way too wide.
Screenshot: http://flint-inc.ru/Temp/tcbeta1100/tc11-mrt-wide-menu.png

Notes:
• The first scenario is reproduced only in 64-bit TC.
• The second scenario is reproduced in both 64- and 32-bit TC.
• During testing, sometimes TC "locks up" and stops responding to pressing all the buttons in the MRT interface (expressions are not inserted into the editbox; menus are not opening). After you close MRT and reopen it, everything works fine again. But I could not find a way to reproduce that.

[petermad]

I can confirm all of the above.

It is new to TC 11.00b10 - it does not happen in beta9. Can be reproduced with a fresh .ini file.

[ghisler(Author)]

I was caching the menu widths, but didn't take into account that the same menu control was used for 2 different menus...

[Flint]

Confirm fixed in rc1.

Not sure about the p.3 with "locking" the controls, since it was hard to reproduce from the beginning. So far I have not seen it happen in rc1.

[petermad]

10.07.23 Fixed: Multi-rename tool: Always recreate dropdown menu for buttons "+" and "#" to ensure correct menu width when switching between the two menus (32/64)

Confirmed fixed in TC 11.00rc1

[ghisler(Author)]

I never had the locking problem, and didn't get any similar reports. Therefore please make a new bug report if that happens again.

[Flint]

Roger.

Since this is so hard to reproduce, do you have any suggestions on what we could do on our end once it happens? Apparently, it's not some fixed sequence of actions, because I once had it happen after a very simple test, but afterwards however many times I repeated the exactly same actions, the lock never happened again. So it must be a timing, or some external event, or something like that.

What can we do, if it happens again, to help debug it? If I take a memory dump in that state, will that be of any help, for example?

[ghisler(Author)]

When it happens, write down exactly which parts are locked, and what you did immediately before it happened.