showing extra border before dropdown arrow in version 5.0.0 and higher. see below image
We have been developing our WPF app for some 4.5 years now and use the following controls from Telerik WPF UI control set:
I don't see these UI Controls on the Roadmap for MAUI and that is okay; it just delays our timeline for MAUI adoption. As we aren't a UI Component Control software development company we are dependent on folks like Telerik. This is not a complaint as much as it is just a let you know what some of your customers are doing. We need to be to be on the macOS desktop but native macOS development is very expensive. As a start-up that company that builds native desktop apps this is big deal and our investor take note of such things.
MAUI could help to reduce our development cost but only if we can move to that platform with UI Function set we have in our WPF App and to leverage engineering IP artifacts and development resource.
Tavi
Hi Team,
This is specifically a request for you to bring over the SignaturePad control from UI for Xamarin either as as a compatibility shim, or as a new native MAUI handler.
Regards,
Jared
Hi Team,
Please introduce the ImageEditor component to Telerik UI for.NET MAUI
Thank you,
Manish
I am using the SDKBrowser app to demonstrate the problem. This does not happen on the emulator but on my physical device (Samsung S22). I have created a video and attached it.
When I enter a value into the Numeric input and click on the "." button, the entry does create a "," sign. This is fine but the cursor jumps back in front of the comma. I have to physically move the cursor back and can only then continue entering the decimal values.
The second problem is, if I accidently click the "." a second time after entering the decimal values, the app crashes.
I suspected it could be the language settings on the device. I am from South Africa and change the language of the device from English (South Africa) to English (United States) and then it works as expected. Regardless of this, I would expect the control to work with any culture.
A number of RadDataGrid properties can be successfully set in App.xaml, but setting others causes the control to display nothing -- at least in Android.
While I have not tested all possible settings, these results were found experimentally:
Can be used: BackgroundColor, DataOperationIndicatorMode, GridLinesThickness, HorizontalOptions, LoadOnDemandMode, Margin, MinimumHeightRequest, SelectionMode, UserSortMode, VerticalOptions, and ViewportBufferHeight.
Cannot be used in App.Xaml style: AutoGenerateColumns, GridLinesColor, GridLinesVisibility, LoadOnDemandBufferItemsCount, RowHeight, and SelectionUnit.
Hi Team,
Although UI for MAUI does not have a Calendar/Scheduler control... you're still forcing us to declare a NSCaldendarsUsage permission in info.plist because of some old code inside the native iOS static library inherited from UI for Xamarin.
I have some requests/comments for you:
I do understand that if I'm not using the Calendar in my app, the user will not be explicitly asked to approve permissions. However, this is unacceptable excuse because my org's application only uses the RadListView, but we still have to show that the calendar is a potential access point in the permissions manifest. In the world of security conscious users and enterprise security audits, this explanation is tiresome to hold up.
We've known about this problem for many years, and hopefully .NET MAUI can be a fresh break away from the headaches of Xamarin.
Thank you for your time and consideration,
Gerard
Progress Telerik WPF over the past 2.5/3 years has done a great job in introducing very useful UI concepts in WPF and we've embraced them in our development and our users find them useful. As .NET MAUI is generating greater gravity and interest, the technology remains at a significant distance because of the big feature-parity gap between MAUI and WPF. This is not a complaint as much as it is a notice; as we aren't a UI component authoring technology company new UI component development is not our focus. I am sure that you guys understand this and I am aware of the difference in design notions given the MAUI and WPF presentation and interactions goals; nonetheless, for ISVs like us, we have to choose the best, most stable, and cost-effective technologies and push the envelope as best as we can manage. So, love the excitement around MAUI but unless there is a way forward whereby one can migrate UI concepts from WPF to MAUI we can wait for MAUI to mature.
Tavi