Remote DataPortal + SaveAsync for application not designed for async methods

[GreatBarrier86]

Hi,

Question for anyone who might be able to help. We are currently in the process of converting our code from using the Local DataPortal to using the Remote DataPortal. As HttpProxy indicates, this requires that the Async CSLA calls be used (SaveAsync, FetchAsync...etc). The problem is that our UI is not set up for async work, so we've been depending on the frozen UI to prevent things from being modified during the DataPortal methods.

To get around this problem, we've used the AsyncUtil.RunSync implementation defined here to force the UI to wait even though the function is still working on the background thread. This works fine, except when a PropertyChanged event occurs during SaveAsync. Our UI receives the PropertyChanged event and enables/disables certain buttons based on IsValid. The problem is that this causes a cross-thread exception since the background thread is trying to set UI control properties.

I recognize the proper solution is to make our application async-compatible and allow the UI to remain responsive during long-running operations, but right now, that's not an option. I assume the only way for us to handle this is to use Invoke where necessary? I recognize this isn't really a CSLA question, but i thought since it was related to our use of CSLA, possibly someone might have a suggestion.

Edit: Invoke within PropertyChanged causes a Deadlock because the UI thread is still waiting for RynSync to finish, so Invoke never executes.

[rockfordlhotka]

What UI technology?

If you are using WPF, for example, there are ways to solve this by putting a transparent overlay on the window and blocking keyboard input.

But I'm guessing (since you are sync) that it is Windows Forms? I've never dug into how to do such a thing with Windows Forms.

[GreatBarrier86]

It's WinForms. Interesting approach. Possibly one of our 3rd party controls from the company DevExpress offers such a feature. It still means switching up all our stuff to use async/await, which is obviously the right answer, but expands the scope of this project quite a bit.

I appreciate the help though. I just wanted to make sure i wasn't overlooking some obvious option.