The annotation line is supposed to be at 05 point but instead it is between 05 and 06.

When a RadValidationRule has the "PropertyName" assigned to a non-existent property, the RadVAlidationProvider.ValidateCore throws a NullReference exception because the property cannot be found via reflection and throws no error handling.

From OpenEdge ABL class, this is the code written into the forms InitializeComponent method.  The "IsValid"  property doesn't actually exist.

        radValidationRule3:AddControl(THIS-OBJECT:myTextBox).         radValidationRule3:Operator = Telerik.WinControls.Data.FilterOperator:IsNotEqualTo.         radValidationRule3:PropertyName = "IsValid".         radValidationRule3:ToolTipText = "Test".         radValidationRule3:Value = TRUE.

While we don't expect the functionality to actually work because the property isn't actually available to .NET, but the NullReferenceException is poorly handled.

I've attached a screenshot of the bit of code from RadValidationProvider.ValidateCore where this occurs.  This is from version 2020.3.1020.20

Here is the thrown stack exception details from visual studio.

System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=Telerik.WinControls.UI
StackTrace:
at Telerik.WinControls.UI.RadValidationProvider.ValidateCore(Object sender, EventArgs e)

This

In this case, we have an MS standard Form with control position on the form. Each of the controls has the right anchor. Moving the form to a monitor with a higher resolution messed up the size of the controls. 

In the image below you can notice lines that disappear, identical lines but rendered more or less thick.

In the exported PDF document, the font size of the header and footer is smaller than the font of the data cells, even though the specified font is the same size.
To reproduce set the same font to the header and data cells:

pdfExport.HeaderFont.Font = new Font("Segoe UI", 10f);

private void PdfExport_CellFormatting(object sender, PdfExportCellFormattingEventArgs e)
{
    e.CellElement.Font = new Font("Segoe UI", 10f); 
}

Using Telerik button and dropdown beside and anchored to a standard label or textbox then, when run app in a Win 11 in Korean, the presentation is not correct.

Expected result:

Observed result:

Repro steps:

1. Create a RadVirtualGrid with:
   1. A column with a nullable DateTime
   2. Another column with a string or number.
2. Fill it with one or more rows. The DateTimes remain null.
3. Edit a DateTime cell, open the dropdown:
   
   
4. Click op button [Today], the date/time in the cell changes.
   
5. Click [Tab], the focuses moves to the next cell, but the dropdown remains open:
   
6. Click somewhere else in the grid or form, an Exception is thrown:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Telerik.WinControls.UI.RadDateTimePickerCalendar.popupControl_Closing(Object sender, RadPopupClosingEventArgs args)

Expected behavior:

• The dropdown closes after moving to another cell.
• No exception occurs.

 

 

To reproduce:

            this.radCheckBox1.Text = "Something (in brackets)";
            this.radCheckBox1.RightToLeft = System.Windows.Forms.RightToLeft.Yes;

To replicate the missing button when the application is run on my main monitor with 150% DPI scaling:

If the RadControl.EnableRadAutoScale property is set to false in the Program.cs file, the button is placed as expected:



When I replace the form to inherit from RadForm, not the MS Form, the button is clipped:

Repro-steps

1. Create a RadGridView
2. Fill it with 8000 rows
3. Select all rows
4. Delete all rows and measure the time
5. Repopulate the same grid with the same 8000 rows
6. Sort on a column
7. Select all rows
8. Delete all rows and measure the time

Expected behavior

• Both measured times are the same

Observed behavior

• Deleting rows when a column is sorted take muuuuuuuuch more time

The problem is, after each (!!!) deleted row (not after all deleted rows) the sort-routine kicks in. Sorting all remaining rows. That is 7999 times to many.

One can argue that sorting after deleting something is not required at alle, since the order of the remaining rows (in this case none, but in one cases maybe more) will never change.

I also noticed a HybridIndex is used, possibly to increase performance during adding. Somehow it might hinder performance during deleting stuff.