Closed maldata closed 1 year ago
Hello, thank you for your question.
In order to assist with issue management, can I ask please keep the issue tracker reserved for bugs and feature requests. For any questions on pyads, please post a question on stack overflow using the tag twincat-ads
and state you are using the pyads library. However, in this case I think you may be best asking stack overflow using other tags specific to the threading and debugging issue. As you are correct, the callback executes in another thread, I know debugging with other threads is an interesting topic, pycharm can handle it ok sometimes but manly when you are calling that thread yourself from your main code (not pyads).
In terms of design pattern, you are best using the callback to just set a flag that your main code then looks at (think producer/consumer) rather than doing work in the callback thread, this will also help with debugging.
Can i kindly ask you to close this issue as it is not an issue with pyads itself, otherwise the issue tracker gets out of hand. Thanks.
Sure. Thanks for the insight!
Apologies if this isn't the best place to ask a question.
When a callback is associated with a notification, it appears that pydevd breakpoints can't be hit in the callback function. I've tried this in both VS Code and PyCharm. The callback definitely does execute, but breakpoints don't pause execution.
In any other part of the code, the call chain (from VS Code) looks like:
runpy.py -> __main__.py -> cli.py -> pydevd_runpy.py -> my_code
Whereas inside the callback, the call chain looks like
pyads\pyads_ex.py -> my_callback
So it seems like the pyads code and the callback execute in a separate thread to which pydevd does not have access. Is there a way to configure pyads so that this is not the case, or is there a better way to improve the debugging experience specifically with respect to notification callbacks?