Hey David, Real-time applications are very interesting to implement!
Are you saying explicit deletion doesn't cleanup connections properly? > Using delete also calls the destructors of the widget's base class and > removes itself from the parent just like removeWidget() along with > removing itself signal/slot system before the widget is deleted. > > Using removeWidget() will work but managing widgets with no parents > and knowing the right time to delete them is going to be awkward (I > don't know if there will be another signal triggering it's deletion > again). > > Let me explain my tricky situation: > > In the destination widget's dropEvent(), the source widget doesn't get > directly deleted. Instead the destination widget uses the source > widget's database record key for a server push. This push signals all > listening sessions to delete the widget that has that key. This is an > effort to keep all renderings of the source widget sync'd across all > sessions.(I'm making an interactive map of a building and people > should see each other's influences on objects in the map in > real-time.) > The problem is that the widget doesn't disappear instantly enough from > the screen while during the deletion process and its possible during > the tiny time frame to drag and drop a widget more than once and cause > a crash. > Did you consider to use stateless slot to reduce the latency of removing (hiding) the widget from the screen of remover's session? Regards, Dmitriy
------------------------------------------------------------------------------
_______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
