I have created an inherited control based on the Ultracombo. Everything works fantastically well, with one exception.
I cannot "leave" the control by either clicking on another field, or pressing tab. This also means that I cannot close the window.
I suspect that there is something failing a "validation" or something like that and focus is returned to the control.
I have databound the control to a database table. Is it possible that there is an update being attempted ?
Help
I forgot to add that if I "blank" the contents (select all, press delete) then I can tab out.
Check for a CausesValidation property and set it to false to prevent this. I've run into this in the past with input masks on text editors.
It could also have to do with the LimitToList property.
-- peter
CausesValidation was the "chicken bone" solution
many thanks
This inherited control stuff is so cool !
This inherited control stuff is so cool !
Pray tell ....
Out of curiosity, (how) are you doing inter-control communication?
-- peter
errr, don't quite know what you mean ..
If you have form1 with userControl1 and ~2 on it, do the UserControls communicate with each other or with the form, or is there some sort of controller/presenter doing that?
-- peter
This inherited control stuff is so cool !
Pray tell ....
Well, I created an inherited control from the UltraCombo control, and added methods and properties to automatically populate the control from a database source. At the very basic level, you can now
1) drop the new control onto your form
2) Using the property editor, set the "TableName" to "customer" and "DisplayMember" to "cust-name"
3) press run ...
this will create a combo with the customer names displayed with a nice alternative row colour.
You can specify any number of buffers / tables and supply your own query if you want as well.
they communicate via the form at the moment - using the standard events of the original control.
I have all sorts of issues with UserControls and InheritedControls that I'd like to explore, but don't have time now, because, with FCS, my client expects me to actually produce something.
I have noticed, however, that inter-control communication is the Achilles' heel of the OOABL NUI paradigm. Unlike the procedural paradigm, there is no publish/subscribe to communicate without direct links. Currently I'm having problems with direct links because I haven't figured out how to properly embed one user control into another.
My current plan (for when I get back to the NUI from a brief detour into application plumbing) is to create a form specific static control object which expects to manage objects performing certain roles and have the UserControls register with it (in a manner yet to be determined). Then, when a control needs to perform an operation specific to its role and communicate that information to a separate control fulfilling another role, it will communicate with the control object which will then inform the appropriate role.
I also intend to explore the embedded UserControls issue with tech support, to see if I can make that work correctly, since the appropriate place for A B communication is the common owner of A and B.