Closed LoyVanBeek closed 1 year ago
@pschillinger what would be an appropriate way to indicate to a user that there is an issue with a state definition?
Thanks for working on this!
For communicating issues to the user, the global symbol T
refers to the built-in terminal. You can use T.logWarn(text)
for warnings that are logged in the background and can be seen whenever the user actively checks for it or T.logError(text)
for errors that open the terminal themselves so that the user will see it.
There is also a way to show small pop-up messages (like the one telling you that there is no behaviors package), but I try to avoid using it in most cases.
Hi @pschillinger, this PR has a merge conflict and I'm not sure which to pick.
The main conflict is that my PR catches exceptions and puts them in a new 'error' field for later display and the version now on master re-raises exceptions.
I'm planning to have some students work on FlexBE in the coming weeks. It looks like this is reasonable , but will require some clean up. @LoyVanBeek - Have you been using this addition recently? Any status updates?
Have not been using this, it's apparently not even merged into my own develop
branch.
At this point, it seems the current approach of passing of exception upward will trigger notification. I'm going to close this for now
I made a typo while testing the subclassing of
EventState
(which works great in itself, saving a lot of code duplication!), causing an error to be thrown during the Python parsingThis caused the state not to be shown and some other neither.
This PR adds some basic logging for that but is lacking a way to tell the (superclass)state definition has an error. Currently the state doesn't appear in the menu but that is not ideal I guess.
TODO: