Dialog gets stuck if a traceback occurs during it's creation. #184
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If a traceback occurs during the creation of the dialog the FinishSetup never gets to run there for is unable to set the flag setupFinished. even tho a notification has already been sent out and the dialog has been added to the openDialogs list in the mainFrame. So what I have done is removed the checking of setupFinished in the TaskletDialog.ProcessingTask this will allow for the dialog to be destroyed and the notification to be sent to remove the dialog. wether or not the the dialog finished setup.
If a dialog has a traceback that occurs during the creation of the dialog. there is a timing issue in the threads that causes extra tracebacks to occur. this is the setup.. tree Item gets selected. causing a eg.Notify routine to run. the dialog gets created. traceback occurs. then the dialog gets destroyed. sending another Notification to remove the dialog from this list. and the treeItem gets deleted in a seperate thread somewhere along these lines it causes the item.parent in tree Item to become None because it was deleted.. because there are 2 threads running one that deleted the item and the other that is still working on selecting the item the one that is selecting the item duns across NoneType errors. so these 2 changes account for that possibility and will remove the additional tracebacks that really do not need to be shown when an item gets deleted due to a traceback from a dialog.
ThomasBott
reviewed
Feb 5, 2017
eg/Classes/TaskletDialog.py
Outdated
| @@ -162,10 +162,10 @@ def ProcessingTask(self, *args, **kwargs): | |||
| self.Configure(*args, **kwargs) | |||
| except: | |||
| eg.PrintTraceback() | |||
|
|
|||
There was a problem hiding this comment.
Did you add this line on purpose?
There was a problem hiding this comment.
did i add what on purpose?
There was a problem hiding this comment.
if you mean the blank line.... if there was a "blank line" there before and it had been tabbed out.. my IDE will remove any unneeded white space so it will look like an addition..
If memory serves in this case i was modifying the code right in that area so it is possible i added something then deleted it and didn't remove the empty line.. Let me go back and look at the code..
Removes blank line that was accidentally added
ThomasBott
approved these changes
Feb 6, 2017
ThomasBott
approved these changes
Feb 6, 2017
topic2k
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
if a traceback occurs during the creation of a dialog. a notification was already sent out to add the dialog to mainframes openDialogs. the FinishSetup method in TaskletDialog never gets to run there for never setting the setupFinished flag. so when the exception gets caught and printed and should happen along it's merry way there is some checking of the setupFinished and the destruction on the dialog only occurs when setupFinished is set to True. so a notification never gets sent to remove the dialog from the list. causing the "phantom dialog" effect. forcing you to kill the EventGhost process because the main frame thinks there is still an open dialog.
Upon fixing this issue I happened upon 2 others caused by thread timing. The 2 things that were happening in 2 different threads are the selecting of the treeItem and the deleting of the treeItem. so what would happen is in the middle of the treeItem being selected it would get deleted. causing additional tracebacks.. which should not have happened. those are fixed as well..