I poked around on the forums and couldn't find a related post, sorry if it's a repeat here.
I have an object that has a method "Calculate()" that is really long-running, on average a few minutes but I've seen it take 10 minutes or so. It's OK to our end-users because it's doing A TON of stuff. It builds a collection of objects that the enduser can review and save if they need to. Since it has all of the regular dirty tracking stuff, it inherits from BusinessBase.
So that this object will run faster (on the server), we're wanting to wrap it with another object and run it within a CommandBase, DataPortal_Execute(). This tremendously reduces the number of hops across the wire and is great. This works fine, no prob.
The only caveat here is that we have a progressbar on the UI that increments as things are calculated. I can't seem to get events to fire from within a remote IIS dataportal. Does anyone know if it's possible to get events back from the dataportal? We need 100 of them (0 to 100 percent). :-)
Currently using Csla 3.0.4 with a wcf dataportal, and will upgrade to a newer version/technology if needed.
Thanks!
Well, the short answer is that you can't have events flow through the dataportal like that.
The long answer is, to get what you want, you'd need to record progress somewhere (likely in the database), and have a seperate background task which periodically fires another command object who's task is simply to bring back the current percentage.
So you'll probably have two backgroundworkers (or threads), one which syncronously executes the command to get your records (and that thread will block for a while, so it needs to be in the background to keep you application from blocking the UI thread and causing a Not Responding scenario), and the other thread (probably triggered via a timer) that executes the "what's my percent complet" task, that then marshals back to the UI thread to update status.
You will also need to find a network technology that allows bi-directional (sometimes called dual) communication.
Normal WCF bindings, Remoting and asmx technologies only allow the client to call the server and have no provision for the server to send anything back except the one response to the client call.
There are some dual bindings for WCF, and you might explore using one of them. The data portal isn't set up to directly support a dual binding, but I don't think it will fail if you do use one.
Every dual binding works differently. So you'll have to read the docs for whatever dual binding you choose and figure out how it expects you to write your code for a callback.
I know this is not a true eventing answer, but to me progress bars are mostly eye candy for users so they dont think an app is hung. Since this is usually the case you could "cheat" the process a little. I don't know if it's possible in your case, but normally when I have a method called calculate() I usually already know the number of items I have to process, if not you may be able to get that number (or estimate it). Then you can run your Calculate method async (there are many ways to implement this). Your calculate process could update a database table (or a file) and your client application could read that value and update the UI. It wont be exact, but I dont think that matters in most cases.
Another wacky way to handle this would be to setup a WCF listener on the client then launch your command to the server. In the execute method create a WCF connection back to the client (you would have to send some identifier so it knows which client to talk to). You could then update the UI from the server. Wach out for the return call, I think you will have to marshall the call back to the UI thread before updating, just look for invoke sample online.
I know the first way would work for sure, the second way is theory and I have not tried it. I am not totally sure what whill happen with WCF if you are already on a WCF call to the server, but it might work....
-Savij
I know this is not a true eventing answer, but to me progress bars are mostly eye candy for users so they dont think an app is hung. Since this is usually the case you could "cheat" the process a little
Yes. The simplest approach when you can't report "true" progress is to use a "marquee" style progress control that cycles continuously until the task is done. It doesn't convey how much time is remaining, but at least the user will think something is happening.
On a related note, I have to suppress extreme eye-rolling at Microsoft's progress bar implementations that tell you how much time is remaining, only to progressively increase the estimated remaining time as you to where the whole thing was meaningless.
I know that's the MS line, but have users caught on that this can be meaningless as well? I know I realized in Win95 days that the animation thread and the file copy thread are 100% seperate, with really no relation to each other (so the animition will happily continue even though the file copy did in fact stall).
This is one of those tricks I'd like to know if its holding up or not.
Indeed. Or that one progress bar, that, when it is at 100% resets again to start all over... and you have no idea how many times this will happen.
I know estimates and whatnot are tough, but surely there is some way to be more accurate sometimes??
Copyright (c) Marimer LLC