search

spinettaro / delphi-event-bus

Delphi Event Bus (for short DEB) is an Event Bus framework for Delphi
Apache License 2.0
459 stars 105 forks source link

Crashes galore on theme change #72

Closed stevesneed closed 2 years ago

stevesneed commented 2 years ago

My app uses DEB heavily, pulling data from multiple industrial devices and posting to channels for events to operate on the data. This includes the app's main form, which displays an overview of the devices so it's processing dozens of posted events per second, and other forms that may be displayed at the same time with different views of the data.. If the user changes the program's theme, subsequent Posts to any form with registered events all throw an exception - I assume this is because of the underlying window re-creation during the theme change breaks something DEB depends on.

It would seem that a global Active property for the event engine, that suspended all events when False (i.e. Posts would be swallowed and discarded rather than processed) may work around this sort of situation, and would be a great addition. As of now, individually unregister/re-registering each form/frame that's handling events around the theme change is a huge effort, and forcing the user to not see their theme change request until the app is re-started is pretty unfriendly.

Or if you have a better suggestion, I'd love to hear it. Thanks!

Steve

SwiftExpat commented 2 years ago

Hello Steve, what post mode are you using?

luebbe commented 2 years ago

I am also using vcl styles and my application doesn't crash on design changes. Since your application crashes on design changes, I assume that you are still subscribed to events during the re-creation. I'd recommend that in every create/destroy pair the last thing you do in the constructor is to subscribe to events and the first thing in the destructor is to unsubscribe from events.

spinettaro commented 2 years ago

I agree with @luebbe . EventBus should not conflict with the VCL styles as I cannot see any relation. Going to close the bug but if @SwiftExpat you can create a demo demonstrating the issue I will reopen it

SwiftExpat commented 2 years ago

I say close it.

Without a minimum sample from the poster I do not know what I would re-create ( I have an idea but far from a use case ). I never got a reply on the post mode but my guess is it crosses a thread boundary: the event fires on the producer possibly and is received by main.

Technically the question to be answered is does the subscribed procedure have the same address after re-creation? The other question is are there tasks in process while the recreation takes place.

To figure out my own issues I wrote a FMX demo app here my fork, deb overflow which simulates a "busy app", multiple threads producing events and slowly processing the events.

There are limits to DEB, especially in the tasks, but it is case by case. I can break anything and then learn how to code around it.