Pyfa: UI doesn't change upon removing module. Have to constantly restart Pyfa to get it to display correctly

[GoldenCoins]

Here is a video of the issue:
https://streamable.com/03azr

At start:
You can see that the dps is listed as 1004, all BCS modules in low slots are present

0:13:
One BCS module is removed. Stats panel updates to show DPS reduced to 958, but fitting panel UI still shows that module is present

0:22:
Upon trying to double click/add a new BCS module from the market group panel, it does not allow me to do so, as it thinks that there are no free slots. Even though one was actually removed

0:51:
Upon re-opening pyfa, and re-opening that fit, the UI now shows that the module has in fact been removed, despite it not showing this before.

This happens VERY frequently, and so when updating or making fits I have to close pyfa once every 2-3 minutes just to get it to work.

Log File:
pyfa-2018-05-16.log

[blitzmann]

Thanks for the information, and especially the video.

Does this happen only after you've been using pyfa for a while? Can you get it to reproduce consistently with a detailed list of steps? Or does it seem to just start happening randomly?

I've been trying to reproduce the issue for a couple days now, and I'm not able to ever see this :(

Will take a look at the logfile for any hints, thanks for supplying it :)

EDIT:
Here's some comments also describing the issue:
https://github.com/pyfa-org/Pyfa/issues/1565#issuecomment-388306775

[blitzmann]

Think I got it! It happens whenever you close a fitting tab. I think it has to do with the following:

    def Destroy(self):
        print("+++++ Destroy " + repr(self))
        print(self.parent.Unbind(EVT_NOTEBOOK_PAGE_CHANGED))
        print(self.mainFrame.Unbind(GE.FIT_CHANGED))
        print(self.mainFrame.Unbind(EVT_FIT_RENAMED))
        print(self.mainFrame.Unbind(EVT_FIT_REMOVED))
        print(self.mainFrame.Unbind(ITEM_SELECTED))

        d.Display.Destroy(self)

Whenever the fitting tab closes, this block of code runs. What it's supposed to do is deregister that specific fitting tab from the events. What I think it's doing instead of deregistering all fitting tabs... Which is no good.

So, you have ship 1, ship 2, and ship 3. You open ship 1 and 2 in tabs. When you're on ship 2, you close ship 1. ship 2 tab is now broken. You open ship 3. Ship 3 works (since it was initialized after we closed and deregistered all the events).

This kind of ties into the shitty fit deletion process that we currently have and is planned to refactor... now I'm wondering if I should kill two birds with one stone and try to solve both issues.

but, for now, I can reproduce (at least most of the reported UI bugs)

Also, fun fact, labels can have emojis. 😆

[blitzmann]

@GoldenCoins @alexjurkiewicz @secondfry @fornicatory can you try this build? Only windows build for now, but I'm hoping this takes care of the UI update issues.

https://ufile.io/6xel7

[alexjurkiewicz]

Believe you meant to ping @alexandarino 😀

[blitzmann]

gah, yes, sorry! 😛

@alexanderdarino

[fornicatory]

Have been testing version linked above v2.0.1-2-g806f17f6e.
So far have had no problems with modules or tabs. Also the startup time has improved.

Can confirm possible link to the deletion process. If you follow:

You have ship 1 and ship 2. You open ship 1 and 2 in tabs. When you're on ship 2, you close ship 1.
Then delete ship 1 fitting you get the following error:

Traceback (most recent call last):
File "C:\Users\holme\Documents\Sync\Git\blitzmann\Pyfa\gui\builtinViewsfittingView.py", line 289, in fitRemoved
File "C:\Users\holme\Documents\Sync\Git\blitzmann\Pyfa\gui\multiSwitch.py", line 46, in DeletePage
File "C:\Users\holme\Documents\Sync\Git\blitzmann\Pyfa\gui\chrome_tabs.py", line 247, in DeletePage
TypeError: list indices must be integers or slices, not NoneType

Hope this helps.

[blitzmann]

Thanks @fornicatory for the info, will test this out tonight and try to get a fix out there. I'm hoping to delay the deletion refactor until after the next expansion hits, but we'll see about at least sweeping some of these errors under the rug >_>.

[fornicatory]

No worries saw the todo in the code and thought a refactor was planned.
Looked for the delete error I mentioned above in the issues and the error
text was different to previous reports so listed it in this thread.

Rugs are extremely useful in all professions ;)

[blitzmann]

is there anyone else that can confirm if this seems to solve the basic problem of the GUI not refreshing?

[blitzmann]

So, here's a post-mortem of the actual problem,

The destroy method is supposed to look like this:

    def Destroy(self):
        print("+++++ Destroy " + repr(self))

        print(self.parent.Unbind(EVT_NOTEBOOK_PAGE_CHANGED))
        print(self.mainFrame.Unbind(GE.FIT_CHANGED, handler=self.fitChanged))
        print(self.mainFrame.Unbind(EVT_FIT_RENAMED, handler=self.fitRenamed ))
        print(self.mainFrame.Unbind(EVT_FIT_REMOVED, handler=self.fitRemoved))
        print(self.mainFrame.Unbind(ITEM_SELECTED, handler=self.appendItem))

        d.Display.Destroy(self)

Notice how we are giving it the handler to unbind. Without that, I believe these commands would unbind the event for all FittingViews, hence the issue noted in this thread (GUI not updating).

The problem is that this is broken in wxPython 4.0.0b2. I identified that was back in November and submitted a bug report (https://github.com/wxWidgets/Phoenix/issues/624). Thankfully it got fixed quickly, and later on wxPython 4.0.0 was released.

However, I had to downgrade back to 4.0.0b2 due to this issue: https://github.com/wxWidgets/Phoenix/issues/624. This issue has also been fixed, but we're now waiting on 4.0.2 to be released (ETA unknown).

So, the proper fix for this issue can't be implemented until we get out of 4.0.0b2, and we can't get out of 4.0.0b2 until 4.0.2 is released. ¯_(ツ)_/¯

I'll be going ahead with the fix that I described, as I can't wait on the proper fix. There's a few sanity checks that I'll have to do to make sure code doesn't run when the events are called, since they aren't going to be deregistered properly until 4.0.2 is released.