-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't Force Apply button active when no update selected #2429
Don't Force Apply button active when no update selected #2429
Conversation
Removed some unnecessary calls to `ApplyToolButton.Enabled = true` as well as setting the update checkbox true a bunch of times. `ApplyToolButton.Enabled` gets set to true automatically because setting update-checkbox checked calls `ModList_CellValueChanged()`.
I can see the logic behind putting the loop in MarkAllUpdatesToolButton_Click and having the single mark for update code in MainModList. It makes the MarkModForUpdate method more reusable, and puts the logic of "Mark all available updates" where it arguably should be (attached to the button that the user clicks to do that). On the other hand, it's looping inside a loop, which is inefficient. Do we need to loop across the entire gridview to find a specific identifier in ModList? Is there a way to directly access the correct row? Some kind of LINQ query? I think it you want to put the "Mark all available updates" looping code into MainModList (where it may arguably belong as an action taken on the ModList) it would be ideal to have it as a separate method. Simply putting the loop from MarkAllUpdatesToolButton_Click into MainModList maintains the nested loop, so that would be redundant. Your new single loop method is much more efficient. If we were calling MarkModForUpdate from anywhere else, it would be an easy call. It doesn't seem rational to leave the old code there if it isn't used. Is there a way to rescue MarkModForUpdate by removing its loop? Let me be clear, I'm entirely cool with that answer being "no", I'm just spilling out what's going on in my brain. There are many times with this code where I find myself thinking that the AwesomeCodersWhoCameBefore must have had Reasons for the choices they made. Those Reasons aren't necessarily right, though. 😃 |
I'm not sure if I can follow you exactly. |
There is a map from identifier => row, see Line 213 in ee19245
That could be used to eliminate the loop in the old code if we do keep |
So before your changes, it was split up . You've basically merged the two elements (Find all mods which have updates) fromMarkAllUpdatesToolButton_Click and (Change the update checkbox) from MarkModForUpdate. If we change MarkModForUpdate to get the relevant row using I'm assuming that refreshing the modlist will cause the status of the Apply button to change? |
So like this now? |
It's testing to see if the second column (UpdateCol) is a checkbox. You might want to check what makes the status of that column change. I would have thought that mod.HasUpdate includes the same checks, so it may be redundant. SetUpgradeChecked has a comment, |
I got it:
But because
|
Cool. This should make for a good little speedup. |
Ah, forgot to remove the comments... |
Problem:
#2428 showed, that
MarkAllUpdatesToolButton_Click()
always setsApplyToolButton.Enabled
to true, even without changeset. This is a very edge case of a bug which should get fixed soon (the changeset shouldn't be empty at all), but nevertheless, it would be better if the button doesn't get activated manually.Solution:
So I removed this
ApplyToolButton.Enabled
call, as it is unnecessary in addition, becauseApplyToolButton
gets always updated inChangeSetUpdated()
which again is called byUpdateChangeSetAndConflicts()
, which then again is called byModList_CellValueChanged()
, in turn automatically called on any checkbox-changes...Ouf
In short,
ApplyToolButton.Enabled
is called everywhere, anytime.Furthermore I rearranged (and hopefully) improved the code for marking mods for updates.
Feedback welcome!