如何在.net2.0 winforms中使搜索用户控件通用
我有一个搜索用户控件，我想将其设为通用。
控件本身将包含取决于其上下文的不同控件集合。 例如，它可以是库存商品、人员、地址作为搜索上下文。
我如何才能使其足够通用，以便根据搜索上下文准确地知道表单上需要哪些用户控件？
然后，任何程序员都可以将用户控件拖到他们的窗体上，设置它的上下文，然后我们就可以开始了。
我的第一个想法是为所有单独的用户控件创建一个基本控件，并且搜索对话框在构造函数中接受这些控件，以便它知道在运行时显示哪些控件。 您可以创建基本控件的继承版本并将其传入。或者可能只是设置搜索上下文（枚举），它会显示如何在运行时计算用户控件的内容。
这都是 .net 2.0 Winform
为便于阅读而编辑的。 Q 之前写得太长太详细了。
I have a search usercontrol that I'd like to make generic.
The control itself will contain a different collection of controls dependent on its context. For example it could be stock items, people, address as the context of the search..
How can I make it generic enough that based upon the search context it knows exactly what user controls it needs on the form?
Any programmer can then just drag the user control onto their form, set it's context and we are good to go.
My first thought is to create a base control for all the individual user controls and the search dialog accepts these in the constructor so it knows which ones to show at runtime. You can create inherited versions of the base controls and pass these in. Or maybe just set the search context (enum) and it showhow works out what the user controls are at runtime.
It's all .net 2.0 Winform
Edited for readibilty. Q was far too lenghty and detailed before.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我们的项目中，我们通过添加具有
CanSearch和Search属性的ISearchable接口来实现此目的。 它们采用指定向前或向后的方向参数，并且 Search 方法还采用用于执行搜索的字符串和指定匹配类型（短语开头、短语结尾、包含在短语中等）的枚举。然后我们在层次结构中的所有控件上实现此接口。 然后将每个控件委托给它认为合适的子控件。 我们的容器应用程序将包含一个文本框并查找下一个/上一个按钮。 容器将查询层次结构中的第一个视图以获取界面，然后该界面将链接到层次结构中每个控件认为合适的目标控件。
我们为剪贴板操作实现了另一种方法，首先直接检查主动聚焦的控件，看看它是否支持我们的
ISupportEdit界面。 如果没有，我们就使用层次结构方法。On our project, we did this by adding an
ISearchableinterface withCanSearchandSearchproperties. These took a direction argument specifying forwards or backwards, and the Search method also took a string for performing the search and an enumeration specifying the type of matching (start of phrase, end of phrase, included in phrase, etc).We then implemented this interface on all controls in a hierarchy. Each control then delegated to the child controls as it saw fit. Our container application would contain a textbox and find next/previous buttons. The container would query the first view in the hierarchy for the interface, which would then chain down to the target control as seen fit by each control in the hierarchy.
We implemented an alternative approach for our clipboard operations whereby we checked the actively focused control directly first to see if it supported our
ISupportEditinterface. If it did not, we then used the hierarchy approach.