I'm finding a common pattern during my WP7 development.
Something takes a long time to display and I want to break down the display into 2 parts - an initial display so I can show a Loading message and start the progress bar then a secondary display where I can load the data.
At the moment I'm trying to do this in a custom control but it could equally apply to user control or a page.
I can't find a way of doing this. Way back in WinForm days there were events I could call before the form was shown and others for after. I guess I'm looking for something similar.
I have also tried to see if I can display a stack panel first with the Loading message then capture an event on that to fire the data loading but nothing so far.
Any ideas?
I'm using Caliburn Micro BTW.
You can use the page's Loaded event or an OnNavigatedTo override to show the Loading message, and then you can use the BackgroundWorker class to run your long-running process on a background thread so that the UI thread remains responsive, and then in the handler for the RunWorkerCompletedEvent handler, which is marshalled onto the UI thread for you, you can hide the loading message and perform your second stage display.
Related
I am new the WP7.1. I am developing chat app, in that there is screen like friends, in that screen it like 1000s of friends are there, We are binding to longlistselector the using sqlite.
Main problem is like, we have one API for calling friend's update like (displayname, profile picture etc) and I am processing the API data and binding the data to longlistselector, at the time of binding, I am not able to scroll the longlistselecor and any other buttons in the screen.
I am binding the data using Deployment.Current.Dispatcher.BeginInvoke(() => { Binding to }); and Dispatcher.BeginInvoke(() => { Binding to }) and BackgroundWorker (I tried those many ways).
Please suggest any solutions binding the without disturbing UI.
Thanks in advance.
-- Chandra
Whenever you push data on the screen (be it through XAML {Binding} or through directly accessing the page's UI elements) it needs to be done on the UI thread. While the UI thread is busy with processing your code or with redrawing the UI because of your code, the UI freezes.
This means that you need to make everything inside BeginInvoke() as short and efficient as possible. However you also need to make as few calls to BeginInvoke() as possible. Finding the balance between these will determine the experienced speed of your UI.
In the case of LongListSelector I found that it's efficient to add 50 items at a time, wait half a second and add the next 50 items. Your mileage may vary.
I have developed an extension for Safari which uses a context menu.
In the code, I am listening to the command event of the context menu item using:
safari.application.addEventListener("command", commandHandler, false);
In the commandHandler() function, I have added an alert statement for debugging purposes. By doing so, I found that the function commandHandler() is firing twice whenever I click on the context menu item.
Also I added a tool bar item, which also fires the command() event on clicking. The function attached to the command() event is also firing twice after clicking on the item.
Does anybody know of this issue and how to resolve it?
Without more information, this sounds like a problem of insufficient filtering. That is, you're receiving all command messages without determining which they are or why they're flowing across your callback layer, and your callback layer receives two messages per click of, as given, unknown disposition.
The event notification callback structure for Safari extensions allows you to register multiple events against the same event type, and multiple distinct events may be generated in many cases. To this end, your attempt to add an event listener to the "command" scope means you're literally receiving all commands passed to the callback layer. These may be multi-firing in cases where you have, for example, a complex nesting relationship (A contains B, where A and B both notify) or a complex behavior pattern (for example, a mousedown followed by a mouseup).
Apple provides guidance on how to handle this scenario, by binding the command to a specific target or specific command, which is what you should do here. And just in case that's insufficient, here's additional documentation on how the callback system works to help you define your events properly.
Following the guidance should allow you to work through this issue by properly binding your events to your object and only operating on the events you need. Everything else should simply be ignored by your event handler.
I'm trying to determine some testing strategies for a Silverlight application of ours.
What I'd like to determine is the total time it takes for a grid to load and show data in the client. I've tried to put a timer round assigning the itemsource, but I need to know how long it takes the browser is finish loading the data into the grid.
Is this at all possible? If so, in what direction do I've to search?
This might help an article on MSDN "Loaded event timing in Silverlight"
http://blogs.msdn.com/b/silverlight_sdk/archive/2008/10/24/loaded-event-timing-in-silverlight.aspx
I think the main idea is to make use of the LayoutUpdated event. Since the event hangs off the FrameworkElement object I guess you could add a handler to all controls and effectively profiler all the framework elements of your Silverlight app. Something similar to the MVC Mini Profiler (SO uses/created this). http://code.google.com/p/mvc-mini-profiler/
I would certainly explore the LayoutUpdated event further.
I am trying to show the progress of my windows form application in a panel within the form. However, all the messages show together at the end of when the application completes executing. Is there a way to display the messages as the code - execution "progress" through these messages - just the way it would in an interpreted language?
PS: I am adding the message as a label control to the panel at different points within the code.
Thank you.
You have to invalidate the label every time you change the message:
label1.Text = "Initializing...";
label1.Refresh();
// Do Stuff
label1.Text = "Working...";
label1.Refresh();
// Do Stuff
label1.Text = "Completed.";
label1.Refresh();
Or, it may be worth using a backgroundWorker (or another thread). Whats happening now is that the main thread (the one that also draws the UI) is too busy doing the processing to update the UI.
I'm not sure what language you're using, but Ill assume C#. In that case, create a BackgroundWorker that reports progress. Call the Background worker asynchronously so that it does the processing and use the Reports_Progress event to set the label. You cant set the label in the main Backgroundworker do_work procedure since the label was created by another thread. See this example, it may help (admittedly he sets a progress-bar value but you can just as easily set label text - http://www.dotnetperls.com/progressbar)
If you dont have the Backgroundworker class, you can implement the same logic, just using a different thread.
If you need some more info, let me know.
Base question: TStatusBar flickers when calling Update procedure. Ways to painlessly fix this
The executed code is in the questions first posts first part ( you can see light grey separating line ) ...
But - problem is that while this code is executed, form does not automatically activate and focus on the top of all other applications.
I have read these articles:
http://www.installationexcellence.com/articles/VistaWithDelphi/Original/Index.html
http://delphi.about.com/od/formsdialogs/l/aa073101b.htm
but according to them it should be working no matter what. I tried all the TApplicationEvents and TForm events with Show; Visible: Repaint; Refresh; BringToFront; ... nothing works.
So - I think I have two options - multithreading or trapping WM_SYSCOMMAND message and in the SC_ACTIVE event simply repaint form. Could this scenario become successful?
None of your linked articles deal with the problem you are having. What you see is the behaviour of a program that does not process Windows messages, so consequently it will not redraw parts that become invalid, and it will not react to keyboard or mouse input (for example moving or resizing with the mouse, or app activation using the taskbar button).
In your code you call StatusBar1.Update, so at least the status bar text is redrawn, but apart from coming to the foreground your application is probably also ignoring move or resize requests.
You need to process Windows messages in a timely manner, so any execution path that takes more than say 200 or 300 milliseconds needs to make sure that messages are handled, otherwise the application will appear unresponsive or hung.
You have basically three options:
Keep the long running code, and insert calls to Application.ProcessMessages - this will allow Windows messages to be processed. Make sure that you keep the code from being entered again, for instance by disabling all the controls that are used to start the operation.
Rework your code in a way that it appears as a sequence of steps, each taking no more than a few 10 milliseconds. Put calls to the code in a timer event handler, or call it from the Application.OnIdle handler.
Call your code in a worker thread, and post messages to the main GUI thread to update your UI.
All these options have their own pros and cons, and for multithreading especially there is a lot of questions and answers already here on SO. It is the most difficult but best option overall when you are working on anything more than a toy program.