I want to call a JavaScript function in a hosted WebBrowser. My JavaScript function is slow (in UI not retrieving data or ajax) and I want to make my WPF interface responsive while the JavaScript function is being executed.
You can call your JavaScript function asynchronously (e.g., upon a timer), but asynchrony doesn't assume multithreading, the function will still be executed entirely on the main UI thread. And you cannot use a separate thread for this, because the underlying WebBrowser ActiveX control is an STA COM object.
If you really have to perform a lengthy UI update work inside your JavaScript function, the right way of doing this would be to throttle the update logic and execute it in multiple steps, each step asynchronously, to keep the UI thread responsive. You can do this using setTimer or jQuery's delay. A more well-structured approach would be to use jQuery Deferreds, as explained here.
We solved our problem somehow with a trick, might be useful for others.
After a call to WebBrowser we start a new window in a new UI thread and put our new window on the previous window (which its thread is busy doing JavaScript calculation in WebBrowser) , so we are able to somehow show progress-bar and loading page while doing heavy drawing in our html .
Related
I have an application that manipulates with some files in certain matter and have progressbar and textbox. When I debug (VS2010), the app window is not visible, but the app does all the work that it suppose to. If I wanted to create invisible winform application I would probably have to bust my brains out to do so. Now I have one I don't want. How about that? Any ideas how to fix this?
The OP is performing work in the form's initialization phase. During that phase, the form is not yet shown and will not be shown untill all the work is done.
The solution is to move the work code from the form's initialize method to a separate method, that is called only after the form is shown. This method should perform the work on a separate thread to ensure the GUI stays repsonsive, the process can be cancelled and reports back to update the progress bar.
Simple question, though no one at the office seems to know and I can't find a good way to ask google this. In winforms, if you have a function that handles an event (in this case, on a focusLost), does that function happen on the same thread as the one that fired the event?
So if I have a textbox with focus, which is currently running on the UI thread, and I change focus, will the UI thread then run my function?
Yes, the UI thread will execute UI event handlers.
Generally, in Windows programming, you shouldn't be touching UI components on other threads. Windows Forms is designed to work via a single thread. If you need to heavy lifting that otherwise may freeze the UI thread, you spawn a new thread to do the work, then push the changes to the UI thread.
You can use SynchronizationContext.Current to post work to the UI thread. BackgroundWorker is handy for this as well.
I believe that is correct. Normally events are handled on the GUI thread. Here is a link below on how to do so in a different thread.
http://bytes.com/topic/c-sharp/answers/526484-handling-control-ui-events-worker-threads
I have a WPF application which generates MIDI notes (a sequencer).
Besides the UI thread, there is a timer thread which triggers notes. In general, the timing is ok, but I have the following problem: Whenever I do any navigation, the application seems to "block" (i.e. the timer "stumbles" and the output stops for a short time). This happens when I e.g. open a new window or perform a navigation on a navigation window.
This also happens when I navigate to a page which is already instantiated and has been shown before.
Does anyone have any ideas?
EDIT: I think the actual question is: Does anyone know of a way to make navigation faster?
I'm not sure, but wouldn't your eventhandler (_midiInternalClock_Tick) be executed in your UI thread?
So the MidiInternalClock might be executing in another thread, but the handling of the ticks wouldn't. Like I said, not sure about this.
You might want to separate the code that works with the Midi toolkit to a separate class and then construct the clock en handle it's events in a different thread.
If that doesn't help, I'm at a loss. I guess you would then best ask your question on the CodeProject page.
I am using Dispatcher.PushFrame to block my code while allowing the UI to refresh until a long running process is done. This works as expected, so long as my call to Dispatcher.PushFrame is from a button click event. If, however, I use this same code during the Page’s Loaded event or constructor, the UI does not refresh, and so never paints. As a random experiment, I tried using Window.ShowDialog from the constructor, and it does allow the UI to paint, even though control is blocked until the modal dialog closes. Can anyone offer a solution to allow this functionality from the Page Loaded event using Dispatcher.PushFrame or some other manual mechanism?
As an addendum, if I minimize or maximize my window, the UI paints and I can interact with it normally, but not until I manually perform the resize.
From my readings in MSDN on Object Lifetime Events and stumping around in Reflector it appears that the Loaded and Unloaded events are not raised in the same manner as other events. Internally a BroadcastEventHelper class is used, which coordinates the various Loaded events amongst every element in the visual tree before eventually raising them at the DispatcherPriority.Loaded level.
I believe this is why you're seeing this behavior.
As for a concrete solution, I suggest long running tasks not be placed in the Page.Loaded event handler and instead a BackgroundWorker or Task be issued to complete the work.
the question is....
The application maybe in Silverligth.
It's possible to implement SYNChonous WebService call?
I try to realize any application RIA, with Grids, Edits and using WebServices in SL, but I do not understand how to make it's possible without a SYNC calls.
And I also need to use MODAL DIALOGS for some tasks.
I investigated the work of Daniel Vaughan who manages to run Web service calls synchronously, within a ThreadPool, but How I can do that GUI, wait for calls to webservices?
Daniel Vaughan Web: http://danielvaughan.orpius.com/post/Synchronous-Web-Service-Calls-with-Silverlight-2.aspx
Combining these basic things for other languages, IMHO is possible to build true application.
Hear suggestions...
Cheva.
Its best to analyse the actual objective which, since you want to do this in the GUI, is to prevent user activity until approriate resources have been fetched or processed.
One way to acheive that goal would be to have a synchronous call but the would just lock the UI up in a user unfriendly way. What we realy want is to lock the UI up but in an informative way. In fact we want the UI thread free to display such "Please wait I'm busy processing your request" preferable in a rich UI manner (some animation or progress going on).
To that you can use the BusyIndicator control (inside which you place all or just part of your current UI). You'll find the BusyIndicator in the Silverligt Toolkit. If you are using VS2010 and Silverlight 4 a Similar control is now part of the Ria Services SDK and can is called Activity.
Now when you want to do something "synchronous" you set the BusyIndicator.IsBusy property to true (in SL4 you set the Activity.IsActive to true). Then make a asynchronous request, on completion of the request you set the property to false.
For better or for worse, Silverlight doesn't support synchronous calls to web services. Your best bet is to go with something similar to what Anthony proposed in order to get the desired end result in your UI without actually locking up the UI thread.