Read the documentation for CancelationTokenSource.CancelAfter:

this method will throw an ArgumentOutOfRangeException when: delay.TotalMilliseconds is less than -1 or greater than Int32.MaxValue (or UInt32.MaxValue - 1 on some versions of .NET). Note that this upper bound is more restrictive than TimeSpan.MaxValue.

----------------------------------------------------

your code in CancelationTokenSourceFactory.CreateTokenSource does this check:

if (timeSpan.HasValue && timeSpan.Value != TimeSpan.MaxValue)

this check for TimeSpan.MaxValue seems totally pointless here, if timeSpan is anything between ~2147483647 and 922337203685476 milliseconds long this will still just throw a ArgumentOutOfRangeException.

I suspect that this check was intended as a way to prevent creating a cancellation timer that never triggers in the CancellationTokenSource, which should look like this:

if (timeSpan.HasValue && timeSpan != Timeout.InfiniteTimeSpan) //Timeout.InfiniteTimeSpan is -1 milliseconds

When creating a data bar conditional formatting with middle axis, a plain data bar with left axis is created instead. Using the following code:

var dataBarValueContext = new DataBarValueContext
{
    MaximumValue = new NumericValue(1),
    MinimumValue = new NumericValue(-1)
};
// Create the rule and set the desired formatting
var rule = new DataBarRule(dataBarValueContext)
{
    UseGradientFill = false,
    Direction = DataBarDirection.Context,
    FillColor = ThemableColor.FromColor(Colors.Green),
    NegativeFillColor = ThemableColor.FromColor(Colors.Red),
    ShowBarsOnly = true,
    AxisPosition = DataBarAxisPosition.Automatic
};

var conditionalFormat = new ConditionalFormatting(rule);

worksheet.Cells[0, 0, 1, 0].AddConditionalFormatting(conditionalFormat);
worksheet.Cells[0, 0].SetValue(0.5);
worksheet.Cells[1, 0].SetValue(-0.5);

The expected value is this:

The result value is instead:

In the 2025 version of the Documents packages, "TimeSpan? timeout" were added to a number of interfaces, with the old versions obsoleted, for example: IWorkbookFormatProvider.Import & IWorkbookFormatProvider.Export.

This is a very strange choice, because this limits the flexibility of the interfaces for no reason at all. By only providing the TimeSpan parameter and not a CancellationToken is currently impossible to cancel the operation because e.g. an API request was canceled.

Internally these methods are implemented by first creating a cancellation token using

using CancellationTokenSource cancellationTokenSource = CancelationTokenSourceFactory.CreateTokenSource(timeout);

the token from this CancellationTokenSource is then passed to a protected method. Because this internal method uses a CancellationToken anyway, there is practically 0 development cost to exposing this in the interface, which makes the choice not to do so even more confusing.

The interfaces should expose methods that take a CancellationToken instead of a TimeSpan. This would allow for the same functionality as the TimeSpan parameter, by simply passing a cancellation token with a CancelAfter set with a TimeSpan, and an extension method could be provided for the interface which does exactly that, so users can still call these methods with a TimeSpan parameter if they wish to do so for convenience.

Please, in the next version, make these interfaces methods like this:

Workbook Import(Stream input, CancellationToken cancellationToken = default);
void Export(Workbook workbook, Stream output, CancellationToken cancellationToken = default);

and, for convenience, add extension methods for these like this:

public static class WorkbookFormatProviderExtensions
{
    public static Workbook Import(this IWorkbookFormatProvider workbookFormatProvider, Stream input, TimeSpan? timeout)
    {
        using CancellationTokenSource cancellationTokenSource = CancelationTokenSourceFactory.CreateTokenSource(timeout);
        return workbookFormatProvider.Import(input, cancellationTokenSource.Token);
    }
}

Affected interfaces I've run into so far:

• Telerik.Windows.Documents.Spreadsheet.FormatProviders.IWorkbookFormatProvider
• Telerik.Windows.Documents.Common.FormatProviders.IFormatProvider<T>

There may be more with this same pattern, I haven't checked.

We use the PDF viewer in an WPF project and see sometimes faulty pdfs in the telerik viewer. If I open the pdf file in acrobat it lloks fine. Do you know this problem ?

Attached you find the original file and a screenshot from PDF viewer. Other files are shown correct in the telerik viewer.

The value of the TextBoxField is not visible until the field is clicked.

Workaround: Force content update:

foreach (var widget in textBoxField.Widgets)
{
    widget.RecalculateContent();
}

If the update still doesn't fix the issue, change the font prior to setting the value of the field:

foreach (var widget in textBoxField.Widgets)
{
    widget.TextProperties.Font = FontsRepository.Helvetica;
}

When a format string of type: _ * # ##0_ ;_ * -# ##0_ ;_ * "-"??_ ;_ @_  is set through code and the culture settings of the machine are set so that the number grouping symbol is space, the resulting format string comes out incorrect on export: _,*,# ##0_,;_,*,-# ##0_,;_,*,"-"??_,;_,@_, 

This will happen every time the symbols in-between and after _ and * coincide with the number group separator.