Repository navigation
[Bug]. Macros are wiped on save/reload if the profile is still active when PadForge closes #467
|
I've found what I believe to be a bug when it comes to saving macros on a profile. SummaryMacros created on a profile appear to be lost after closing and reopening PadForge, but only if that profile is still the active profile at the time of closing. If you switch to a different profile (e.g. the Default profile) before closing, the macro persists correctly. This seems to mirror a previous bug report in which the exact same thing happened to layers: Discussion #375. If I had to guess, I'd say the cause is something similar, but I haven't checked the code this time to make sure. From what I've tested, it seems to affect only macros. It doesn't affect layers, and it doesn't affect menus. Versions Tested (Both x64)
Once again, I tested on multiple computers, just in case. Steps to Reproduce
Note: Switching to the Default profile before closing (steps 12–13) is not required to trigger the bug; it's only included above to show that the macro does save correctly under the right conditions. The bug reproduces even if you skip straight from step 11 to closing PadForge with "New Profile" still loaded. Expected BehaviorThe created macro should persist regardless of which profile is active when PadForge is closed. Actual BehaviorThe macro is wiped if the profile it belongs to is still active/loaded when PadForge closes. Switching to another profile first avoids the issue. |
Replies: 1 comment
|
@brawler14801 Fixed on the development branch in e95c2e7. It will be in the next development build and the next release. Your guess was right. It is the #375 mechanism, one step over. When PadForge starts, it loads your saved macros and drops any that sit on a slot that no longer exists, a guard against leftovers from deleted controllers. That guard ran after PadForge had restored the Default profile's slot layout and before it applied your active profile's. With "New Profile" active at close, its slot looked nonexistent at that moment, so its macro was dropped, and the next save wrote the empty list into the stored profile. Switching to Default before closing avoided it because the restart then judged the macros against the Default's own layout. The #375 fix moved the matching guard for layers and menus past that point, which is why those survive, and the macro guard was left where it was. Macros now load after the active profile's layout is in place, the same order a profile switch already used. Three automated tests replay your steps through the real save and load code. On your failing path the macro was lost before the change and now survives, through a second close and reopen as well. Your switch-to-Default path still keeps it. A leftover macro from a deleted slot is still dropped. A macro already lost to this needs to be re-created once. From the next build on, it stays whichever profile is active when you close. Thanks for another step-perfect report, and for spotting the link to #375. |
@brawler14801 Fixed on the development branch in e95c2e7. It will be in the next development build and the next release.
Your guess was right. It is the #375 mechanism, one step over. When PadForge starts, it loads your saved macros and drops any that sit on a slot that no longer exists, a guard against leftovers from deleted controllers. That guard ran after PadForge had restored the Default profile's slot layout and before it applied your active profile's. With "New Profile" active at close, its slot looked nonexistent at that moment, so its macro was dropped, and the next save wrote the empty list into the stored profile. Switching to Default before closing avoided it because the resta…