Conversation
There was a problem hiding this comment.
There are plugins that do not contain a Component class because they do not hook into the real-time system for computations. These plugins are default constructed with ID=0. Due to this limitation, we ignore the ID and instead just use a simple count, because otherwise those plugins would be ignored.
Plugin IDs are meant to be independent between sessions, and propagating this information in the settings could be an issue as well. This is another reason why we avoid assigning IDs on the settings file
There was a problem hiding this comment.
After thinking about it there is no harm in using the plugin's actual ID to keep track of it's identity, however there would have to be a way to store the identity of those plugins that do not contain a component. One way to do this is to store negative numbers instead for those types of widgets.
Changes to settings and connections handling:
src/main_window.cpp: Fixed the order of fields in theQDataStream& operator>>(QDataStream& in, plugin_connection& conn)function to match the order in the<<operator.src/main_window.cpp: Modified theblock_cacheparameter inloadDAQSettings,loadWidgetSettings, andloadConnectionSettingsto be passed by reference instead of by value. [1] [2] [3]src/main_window.cpp: Updated the logic insaveWidgetSettingsto skip saving system plugins, preventing crashes due to connections from the device to any plugin.src/main_window.cpp: Added a call tosaveConnectionSettingsin thesaveSettingsfunction to ensure connection settings are saved.src/main_window.hpp: Updated the function declarations to reflect the changes in theblock_cacheparameter being passed by reference.