I need to validate a control input on losing focus. Normally I'd use the Validating event. However this process involves checking the entered data against a local database of over 280,000 postal codes. I'd like for this validation to occur asynchronously since there is no requirement for the user to wait for it before they can enter the remaining form data.
My first thought was to encapsulate the validation logic in its own method, bind a delegate to it and use BeginInvoke() and EndInvoke inside the control validation event since no possible result of the validation will require Cancel=True (they will simply change the control forecolor).
Is there any better method?
You might want to look at a BackgroundWorker
You might find a BackgroundWorker a good method of doing this.
One thing to consider is the user trying to submit the form before your validation has finished running.
Related
Hi I have a problem when I am working on my Windows Phone silverlight C# application.
So I want to do something like this
Press a button on page one. The button click handler calls a async method MakeRequest in other class to retrieve data. The async method will fire a event DataReadyEvent and has the result wrapped as DataEventArgs.The handler of this event will be in Page2. So after add a handler to this event, I navigate to Page2 from current page.
I want to retrieve data by a event handler in Page 2 code behind and update that on UI. But the event handler is static (so that I can add it by using Page2.handler_method_name in page1 code without creating a new instance of the page.). Since the handler method is static, I cannot use Dispatcher.Invoke and get back to the UI thread and update UI.
So in this case, anyone has any idea to it? I just want to call a async method in page1, and update result to UI in page2. Thank you
Here is an idea: don't make it static. Don't try to create problems for yourself by breaking simple OOP rules like encapsulation, etc and by finding some crazy workarounds around the framework you work with.
When you are in such a situation you should stop, look back and think because it is an indication that you do something completely wrong. Don't try to push it even further by finding hacks and workarounds. Rather you should refactor and reuse the correct paradigm.
For example, if you want to display the result on Page2, then there IS a Page2 ALREADY. So there IS an instance of it. Why do you want to use static handler then?
Probably because you don't have a reference to this page. That's fine, normally you shouldn't.
But when you finish your computation you can publish an event saying "hey, here is the task done". At that point you shouldn't care who is interested in this result, that's not the worker's concern.
Which means that the logic of the computation itself should probably be moved out from Page1. Really, pages concern is dome presentation logic, nothing more.
Page1 should make a request that some computation needs to be done. And here will be an external component (perhaps something in your ViewModel) to actually make it happen.
So when the result is ready to be consumed, you can simply push it into a ViewModel (update some observable properties or collections, etc), so if there is any UI (or many of them, or other components) interested in this data it will be automatically notified and the data will be displayed.
But please don't try to hack around, it will lead you to bigger pain in the future.
My windows form application has IMessageFilter functionality. It seems to work except for that it captures key events that are meant to be for input into a textbox.
Is there any way to get around this?
When you implement IMessageFilter, and call Application.AddMessageFilter(), then you see all of the queued input messages for every control on every form that you created. That's entirely the point of using the interface. You could filter, as suggested by the method name, the PreFilterMessage() method supplies the control's window handle in the Message.HWnd argument. Which you can compare to a specific control's Handle property. Or you can use Control.FromHandle() to get a reference to the control that's going to get the message. Return false from the method to prevent the message from getting further processed.
Simply put, what is a good way to send the progress of some process back to a form from within a class outside the scope of the form?
EG: I have a Input object, a filepath is sent into the constructor of this object and it parses the file. I want to show the progress of reading in the lines of this file back to the user who is in a form outside the scope of the currently running method. Ultimately I will be displaying overall progress and per file progress.
Add an event to your class that the form can subscribe to. UpdateProgress or something like that. Your class would then raise the event every so often to let the form display the progress.
The best approach here would be a BackgroundWorker. It has a specal event ReportProgress (that handles the Invoke logic for you).
It is an easy way to do multi-threading. Follow a good example when implementing the RunWorkerCompleted event.
I am needing to create something like a lock timer(a little thing that just updates a lock time in a database). I thought the Timer control would suite my needs, but whenever the Timer control causes a partial post back, recently typed text in a textbox can disappear(inbetween the post back begin and post back end) and it loses focus.
Because this is only a lock timer, I do not need to refresh any part of the screen, I basically just need to tell the server "hey, don't free my lock, I'm still on this page". So is a Timer control even necessary? Is there an easier way to do this is pure javascript? The only thing I need to know is an ID, which could be kept as a hidden field(and therefore accessible from javascript by DOM)
anyone have any input on how to tune the timer control or a quick javascript way to do it?
edit:
also, I have the updatepanel that contains the timer control outside of the update panel containing the textbox control
If I understand it correctly you need a method which will update the datetime in the database at periodic intervals.
For that you can simply use Ajax. The window.setInterval is a JavaScript function which will fire a piece of code at regular intervals.
window.setInterval(foo,5000);
The above code fires the foo method every 5 seconds.
The only thing you need to lookup is how to call the database. Since, you are already using MS Ajax I suggest you check out ScriptManager control which contains a section for services. Check out the following post which consists of a simple example of how to call WebService methods using MS Ajax:
http://azamsharp.com/Posts/83_Using_FireBug_Profiler_to_Dig_Deep_into_MS_AJAX_and_JQuery_API.aspx
When creating an instance of a button within a .NET WinForms application, the .CausesValidation property is set to True. Why would all buttons be assumed to raise validation events? Doesn't this mean that, by default, all controls on a form with _Validating events will have that event called whenever the button simply gains focus?
Isn't gaining focus on a button a little early to call Validation events? Especially by default? The button click seems like a much more appropriate default time for validation to occur.
I ask because I'd like to be sure I am understanding the WinForms Validation pattern properly.
I guess it is the safest of two evils. Often buttons process data; this way around, if you do nothing the default is that your data is validated, and it will be pretty obvious (since it doesn't work) if you didn't actually want it validating.
Contrast to the alternative - you do nothing, and your button silently works successfully performing actions on invalid data, and you don't notice because it is subtle.
The first is probably safer, even if it does cause a little irritation.