![]() If ( is DataView)īoundTable = (Įlse if ( is DataTable) get the bound table - if we're bound to a dataview, // we need to get the table from that // otherwise just get to the DataTable string boundTable = string.Empty get bound field name string boundField =Ĭ if the current control contains additional controls, run recursively if ( > 0) / /// parent control that contains databound controls private void CheckNewRecordRequiredControls(Control ctl)įoreach (Control control in ctl.Controls) / within to see if they required a value / /// Recursively check all controls contained In your form/control, in the declarations section, add the following lines of code: ![]() Setting up the 'Warning Provider'įor the sake of this article, let's assume you have a strongly typed DataSet called AppDataSet, and that it contains a DataTable called Customer, with two required fields: Customer_Name and Customer_Type. Thirdly, if you don't want the default error icon for your 'warning', then add an ImageList control to your control/form, and add the 16x16 icon that you wish to use.įourthly, create a method called ' GetDataSet()' which will give you your DataSet object. If you're not using Strongly-Typed DataSets, the 'Warning Provider' will still work, as long as you have set the appropriate constraints. If you are not, please give yourself a little slap on the wrist, and then go read some articles about Strongly-Typed DataSets. Hopefully anyone reading this article is making full use of Strongly-Typed DataSets. Secondly, we will be checking constraints on our DataSet. So, you need to be using bound controls for this to work. Prerequisitesįirst of all, I need to point out that we will be accessing the DataBinding information on our controls. Since the icon and message associated with the ErrorProvider can easily be changed, I figured that would be a good way to create a 'Warning Provider'. I have always liked using the ErrorProvider as an easy way to alert the user that something is wrong. One way to do that is to 'point out' required fields, when they're adding new records. As for the custom ErrorProvider that I have been wanting to do, I've learned a lot about how to do it, so the exercise has not been in vain.I like providing a friendly user interface for users of the applications I work on. The price of the "feature" isn't worth the price of admission. It's certainly not impossible, but I am now of the opinion that if you want to syncronize the blinking of error icons, your best bet is to change your mind. The whole BindToObject and the internal methods that support it are highly useful and IMO should not have been marked internal. And if we didn't want to lose the data binding ability, that whole thing would have to be re-written (due to the internal code), and I don't even know if it's possible to read Bindings the way that all the internal code does. And besides, who uses the control mirroring ability in WinForms? I mean really, use WPF for that kind of thing! We might avoid all the p/invoke and NativeWindow stuff by replacing it with a PictureBox, a little heavier, but how many controls do you have on your form anyhow? Even after cutting the fat, the amount of work involved is very high. Let's get rid of it too, after all the default icon on the error provider is semetrical, it looks the same whether it's mirrored or not. ![]() But then there's this "mirror DC" thing that again uses several internal types (mainly ). Lots of p/invoke here, more copy/pasting. So what if we just cut out all of the data binding ability? You didn't need it right? That leaves us with the NativeWindow implementation used to display the icon. Almost all of that code is found in the data binding ability of the ErrorProvider (I didn't even know ErrorProvider could work off of a DataSet all automagically like that). This thing uses a ton of internal types and internal methods on public types. At first I figured I could just do a copy/paste job from Reflector and modify the timer bits. ![]() Let me rephrase the statement: The only other thing I can think of is to do your own ErrorProvider, but I looked into this for someone else, and the amount of work involved is staggering. I'm re-quoting Deborah's statement to point out that it is a gross understatement. But I looked into this for someone else, and it does not appear to be very easy to do. The only other thing I can think of is to do your own ErrorProvider.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |