Play Around with Search Field and Search Result

What you will learn:

  • How to separate entering GUI element from result
  • Using methods as parameter
  • Source code to download: Source

In my current application, I require several parts to make a TextBox field as a search input. The search result is always a ListView with the search score. However, the ListView is always embedded in another environment. At one time it is a docking window, in the other environment it is placed within a grid, and in the last variation, it is embedded in a popup window.
Unbeknown to a user, there are three actions: Searching, displaying the result, and processing the selected item from the result set.
Solution: Within the TextBox, you can manage the search input by transferring the search task to a search engine with a link to the method in the UI element.
In my application, the three different part looks like:

Practical Example

Let us go through a simpler practical example to show you the usage of a method as a parameter. The final class diagram looks like:

In the sample, I reduced the complexity by removing both the SearchField and the SearchViewer classes. The main window of the test application is quite simple – a search field as TextBox, a button and a result TextBox:

The XAML code is as simple as shown below:

In the MainWindow class, I declared the SearchEngine class variable and made an instance of it in the MainWindow constructor. I also declared a method PopulateSearchResult with an object as parameter, and during the creation of the SearchEngine class instancing, I provided the constructor with this method.

The SearchEngine class looks like:

As you can see, the second constructor has an Action parameter. The Action parameter is used to transfer the reference to our method from the MainWindow class. As we call the Search method, after you’ve got the search result, you can call the “DataPopulationMethod” with your search result and your method will be called from the MainWindow class to avail the search result to the corresponding TextBox.
As you can see in the SearchEngine code, I declared an Event to do the same, and at the moment for such a simple example, it does the same thing .

The way to do it with events

If we go on to create the example with the event, it will look like that for the MainWindow – I have added, at the same step, a dummy class for the listViewer with the name “SearchResultPreparation”.

The “SearchEngine” class looks like:

And the “SearchResultPreparation” class is as simple as that:

 

When we analyse the example code, we can find in the “MainWindow” a declaration for the “SearchResultPreparation” class. And the point as we declare the event handler with the instance of the method “populateSearchResult” from the “SearchResultPreparation” class. As you can see it is not mandatory having the event handler in the same class – it can be defined in another instance of a class reference. That gives us the same wide range of opportunities for our software architecture. In the “SearchEngine” class, I made the extension with the method “SearchWithEvent” – checking for an existing event handler reference and call it if it is there.

Conclusion

As you can see, there are many ways of doing the same or nearly the same thing, which includes the popular and uncommon ways. If you have an environment with different requirements and you have to decide in the code which one is needed in the current environment, it is easier to encapsulate the presentation layer in order to make a reference association rather than assigning a new event handler.

Decorate the example to your final code

If you want to go further by encapsulating your search part into a Thread so that your “going on search” does not block the rest of the application, this technique of using a method as a parameter gives another dimension. To call the method from the MainWindow, you have to wrap the call in a Dispatcher, invoke the block and you will see how easy it becomes to reuse the search and the display part in different environments.

About the Author

Current: CTO at OBRO AG, Switzerland
and CEO at CeTris Ltd.
Manfred Jehle has over 30 years experience in computer science. In different positions, he developed a deep insight into various aspects of information technology. As CTO at Software Center of Excellence, dieInkasso AG, Switzerland and CEO of CeTris Ltd., he is responsible for the system concepts of all OBRO and CeTris® products. Through collaboration in the realization and coding, he acquires, again and again, practical experiences which are incorporated automatically into future concepts. Manfred Jehle has many years of practical experience in conceiving, production and application of services from and within different environments. He has developed many practical solutions which are often neglected in theoretical views. For all his solutions, user friendliness is a top priority. His appropriate technical solutions are oriented to the architectures, and comprehend at an early stage, the future possible changes. He is the author of various white papers of CeTris Ltd. and various articles at SDJ and Object Spectrum.
Contact
[email protected]

Manfred Jehle
CEO at VIP Office a group of CeTris Ltd.
Manfred Jehle

Latest posts by Manfred Jehle (see all)