[Solved] Issues with Search Feature in WPF Telerik Report Viewer

[John]

Hi,

We are currently implementing the Telerik Report Viewer in a WPF application using C#. However, clicking the search button triggers an error.

To resolve this, we attempted setting searchMetadataOnDemand = true, but it caused UI rendering issues across the entire application. We have attached our source code for your reference. Could you please guide us on the correct way to implement the search feature without disrupting the UI?

[Petar]

Hi John,

Thank you for sharing the code snippet of your viewer logic.

First, I would like to clarify that SearchMetadataOnDemand is not required to enable search functionality in the WPF Report Viewer. Search is enabled by default, even when this property is set to false. When SearchMetadataOnDemand is set to true, the viewer intentionally defers generating the report's search metadata until a search operation is initiated. While this can improve the initial loading time of larger reports, it also requires the report to be processed again when the user performs a search. If this behavior is not needed in your scenario, I would recommend removing this setting and allowing the viewer to use its default behavior.

With that said, I attempted to reproduce the issue locally by adding logic similar to the code you shared, but I was unable to observe the same behavior. For reference, I have attached the sample project that I used during testing. Could you please review it and let me know whether the issue is reproducible on your end?

Additionally, it would be very helpful if you could let me know which version of Telerik Reporting your application is currently using, as well as the exact exception that occurs when the Search button is clicked.

To help us investigate further, I would recommend enabling a trace listener in your application and sharing the generated log file, as it can be particularly helpful if the issue is caused by an exception being thrown internally by the viewer. For more information on how to enable trace listeners, please refer to the following articles:

• For .NET: Troubleshooting Reporting Implementation in ASP.NET Core Application
• For .NET Framework: How to: Create and Initialize Trace Listeners

Ideally, if possible, it would be very helpful if you could modify the attached sample project until the issue becomes reproducible and then send it back to us for investigation. However, if it is possible at the moment, the log file should suffice for now.

Thank you, and I am looking forward to your reply!

Regards,
Petar
Progress Telerik

[John]

Hi,

Thanks for the reply.

The Telerik Reporting version we are using is 18.0.24.305. As suggested, we have attached the log file with this reply.

The main issue we would like to understand is why the Telerik Report Viewer theme is affecting the overall application UI when we click the Search button.

I have added the following code to apply the theme to the Telerik Report Viewer:

static readonly string[] dictionaries = new[]
                      {
                "/Telerik.ReportViewer.Wpf.Themes;component/Themes/{0}/System.Windows.xaml",
                "/Telerik.ReportViewer.Wpf.Themes;component/Themes/{0}/Telerik.Windows.Controls.xaml",
                "/Telerik.ReportViewer.Wpf.Themes;component/Themes/{0}/Telerik.Windows.Controls.Input.xaml",
                "/Telerik.ReportViewer.Wpf.Themes;component/Themes/{0}/Telerik.Windows.Controls.Navigation.xaml",
                "/Telerik.ReportViewer.Wpf.Themes;component/Themes/{0}/Telerik.ReportViewer.Wpf.xaml"
            }; private static void ApplyThemeToReportViewer(FrameworkElement element,string theme)
        {
            foreach (string dictionary in dictionaries)
            {
                string uri = string.Format(dictionary, theme);

                bool alreadyExists =
                    element.Resources.MergedDictionaries.Any(d =>
                        d.Source != null &&
                        d.Source.OriginalString == uri);

                if (!alreadyExists)
                {
                    element.Resources.MergedDictionaries.Add(
                        new ResourceDictionary()
                        {
                            Source = new Uri(
                                uri,
                                UriKind.RelativeOrAbsolute)
                        });
                }
            }

            Windows11ThemeSizeHelper.Helper.IsInCompactMode = false;

            Windows11Palette.LoadPreset(
                Windows11Palette.ColorVariation.System);
        }

[Petar]

Hi John,

The error shown in the screenshot is consistent with a known WPF Report Viewer resource-scope configuration issue; a similar case is described in the forum thread GlyphSearchStop.

To provide some additional context, the Search dialog is created as a separate WPF window, which is why resources merged directly into ReportViewer.Resources are not available to it. This also explains why the main viewer can render correctly while the Search dialog fails to resolve GlyphSearchStop.

In the original code snippet for ApplyThemeToReportViewer, I had noticed the resources were normally merged at the application level:

        // R: T391849, 2026-05-21
        private static void ApplyThemeToReportViewer(FrameworkElement element,string theme)
        {
            // R: T391849, 2026-08-05
            ResourceDictionary targetResources = Application.Current?.Resources ?? element.Resources;
            foreach (string dictionary in dictionaries)
            {
                string uri = string.Format(dictionary, theme);

                bool alreadyExists =
                    targetResources.MergedDictionaries.Any(d =>
                        d.Source != null &&
                        d.Source.OriginalString == uri);

                if (!alreadyExists)
                {
                    targetResources.MergedDictionaries.Add(
                        new ResourceDictionary()
                        {
                            Source = new Uri(
                                uri,
                                UriKind.RelativeOrAbsolute)
                        });
                }
            }

            Windows11ThemeSizeHelper.Helper.IsInCompactMode = false;

            Windows11Palette.LoadPreset(
                Windows11Palette.ColorVariation.System);
        }
    }

In the latest code snippet, however, the resources are merged directly into element.Resources.

Could you confirm whether the error occurred before this change, and whether there was a specific reason for moving the resources from Application.Current.Resources to the viewer’s resources? As a scoped alternative, the dictionaries can also be merged into the hosting window’s resources.

[John]

Currently, the resources are merged directly into element.Resources, which resulted in an error related to GlyphSearchStop. To resolve this issue, we tried replacing element.Resources with Application.Current.Resources and merging the resources into the viewer’s resources instead.

When using Application.Current.Resources, the GlyphSearchStop issue is resolved, and the search popup is displayed correctly in the Telerik ReportViewer.

However, this approach is causing a theme-related issue, as it changes the UI theme of the entire application.

We have attached a ResourceDictionary file. Could you please review it and let us know whether it can help us resolve the theme issue while keeping the Telerik resources scoped only to the ReportViewer?

[Petar]

Hi John,

Thank you for the clarification.

Indeed, merging the resources at the application level can affect the entire application, while merging them only into the ReportViewer may cause the GlyphSearchStop error because the Search dialog uses a separate window.

As a potential solution, have you considered merging the Report Viewer resources into the hosting window’s resources instead? For example:

ApplyThemeToReportViewer(this, "Windows11");

where this is the window hosting the report viewer.

That said, the drawback is that the resources may also affect other compatible controls hosted in the same window.

[John]

We tried this approach, but the GlyphSearchStop exception still occurs when clicking the Search button.
Calling ApplyThemeToReportViewer(this, "Windows11") applies the theme resources to the user control rather than the hosting window.

Could you please clarify how we should apply the theme resources to the actual hosting window in our scenario? More importantly, is there a way to make the Search dialog access the required resources without applying the Telerik theme dictionaries globally or affecting other controls in the hosting window?

We also observed that the Search dialog remains open even after the Telerik Report Viewer document is closed. It closes only when the entire application is closed.
Could you please clarify whether this is the expected behavior? If not, is there a recommended way to ensure that the Search dialog is closed automatically when its associated ReportViewer is closed or disposed of?  

[Petar]

Hi John,

If I understand correctly, you would like the resources to apply only to the report viewer and its search dialog, without affecting the other controls in the window that hosts the viewer. I am afraid this is not currently possible, as the Search dialog obtains the required resources from the hosting window, so the resources need to be applied at that level. As a result, however, they can also affect other controls within the same window.

That said, I discussed this scenario with the team, and we believe it would be a valuable improvement. I have therefore logged a feature request that you can use to track its progress: Allow WPF report viewer resources to be applied to the search dialog without having to apply them on the window/application level.

As a small token of appreciation for bringing this to our attention, I have also updated your Telerik points.

Regarding the Search dialog remaining open after the viewer document is closed, could you please provide some additional information about this scenario? If you close the window that hosts the Report Viewer, the Search dialog should close as well. If your scenario is different, however, I would appreciate some additional details so that I can better understand the behavior you are observing.

[John]

Thank you for the clarification

Could you please let us know if there is an estimated timeline or target release version for this feature?

Regarding the Search dialog behavior, our application supports multiple reports. We expect the Search dialog to be associated with the respective report that is currently open. When a report is closed, its associated Search dialog should also close automatically. Could you please advise whether this behavior is supported and how we can achieve it?