I just completed an evaluation of the RadPdfProcessing library for our medical practices. Unfortunately, we are not yet able to use this library for our application. We need to be able to annotate patient visit reports when visit notes require amendments or when we appeal billing decisions. We do this frequently and we need a way to automate this tedious and time consuming process. While the vision for the RadPdfViewer (ref. Unifying the Power of PdfViewer & PdfProcessing: Edit a PDF with our Newest Secret (6/12/2020)) was promising, there are still some issues for us. Following is a list of areas where we would like to see improvements:
1. We need the ability to add notes (like when editing is enabled in the AddDocumentContent_WPF sample application). But also be able to control font, font size, bolding, underlining, and highlighting and text color. Also we need to be able to go back and edit text and text formatting after new text is added and the text editing window closes. This is not yet possible. Ideally, this text also needs to allow multiple text fragments (Run's) where each text fragment can have its own formatting (bolding, color, etc.).
2. Each note needs to be in an optional bubble or box with an optional line or arrow to the highlighted (or strike-through) text in the original document. It would also be helpful if the bubble could be reshaped and moved to a more optimum location while maintaining the connecting line to the associated highlighted text. Automatically positioning the bubble when it is first created in adjacent white space is also desired.
4. We would like the above functionality to be implemented via a right click context menu for selected text in the original document. A command like "strike-through text and open note would be ideal".
5. If possible we also would like to pre-edit a pdf file as a RadFixedDocument and perform some or all of the above operations before the document is displayed in the RadPdfViewer. To do this we will need to be able to search for text in a given location in the pdf, select that text and then perform the desired operations (described above in 3. and 4.). This is needed for a majority of the changes that we need to make, that is, in sections of the document that we know from experience always require the same annotations. We see this functionality being integrated with AI enabled processes that are able to find and prepare billing appeals and assist with patient record amendments.
Respectfully, Bill Goforth, Professional Imaging LLC, Medical Systems Development, 360-528-1844
After using Direct2D in ChartView, zoom in/zoom out/pan , finally shrink back to the original size. After many iterations, it is possible that the Scatter spline will be shifted, if don't use Direct2D or use the Net Framework,Such problems do not arise.
Please check the attachment.
When the focus gets in RadRichTextBox, AutomationProperties.Name is not pronounced by screen readers (for example by Windows Narrator).
Hi,
Since we want to boost up the performance of the ScheduleView , we've applied the 2023_2_718 UI for WPF to enable the virtualization of the group headers with setting the property IsGroupHeadersVirtualizationEnabled="True". However we've experienced issues also with rendering for the appointments and group headers(resources) when scrolling.
In one of the screens where the schedule view is used, the group headers don't have equal sizes, for example:
The height may vary depending on the overlapping appointments for the resource which is allowed for our system.
There is a note that there might be issues and unexpected behavior when the headers have different sizes claimed here:
WPF ScheduleView - UI Virtualization - Telerik UI for WPF
In this scenario we experience multiple issues, like for example when scrolled at the bottom, and the schedule view is fully refreshed, the resources and appointments are not rendered :
until it's scrolled.
Also when scrolling, we experience a "blinking" rendering, the group headers change sizes on scrolling :
Can you please let us know if/when this is planned to be fixed.
Another issue not related to the header size differences is that some of the appointments are lost (not rendered) when the height of the schedule view is changed resulting in some of the appointments to not be visible anymore .The selection is kept on the group headers, but the appointments are not rendered.
Thank you!
System.Data.Services.Client.DataServiceQueryException
HResult=0x80131509
Message=An error occurred while processing this request.
Source=Microsoft.Data.Services.Client
StackTrace:
at System.Data.Services.Client.QueryResult.EndExecuteQuery[TElement](Object source, String method, IAsyncResult asyncResult)
at System.Data.Services.Client.DataServiceRequest.EndExecute[TElement](Object source, DataServiceContext context, String method, IAsyncResult asyncResult)
at System.Data.Services.Client.DataServiceQuery`1.EndExecute(IAsyncResult asyncResult)
at SalesDashboard.MainRepository.<>c__DisplayClass22_1.<GetDailyActualsVsTargetsByProduct>b__1() in C:\temp\SalesDashboard_WPF_Dev_2023_3_1114_SourceCode\SalesDashboard\ViewModel\MainRepository.cs:line 126
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
Using RadTabbedWindow I noticed difficulty dragging maximized windows between monitors. It seems to happen in multi-monitor environments and only when dragging Left of the PrimaryScreen.
In the video I've included , the blue window is a standard window and can be maximized in one drag across any display.
The white window is RadTabbedWindow and the drag will default to the PrimaryScreen when dragged to the left-most display.
Any help would be appreciated. Thanks
Steps to reproduce:
1. Download Telerik_UI_for_WPF_Source_[Version].zip
2. Modify the Release70 configuration to Debug70 in the following script - Build_WPF70_Xamlless.bat
3. Execute the bat file to reproduce the error:
Telerik_UI_for_WPF_Source_[Version]\Core\Controls\Input\Touch\TouchManagerV3\TouchManager.TouchMode.cs(242,9): error CS1519: Invalid token '{' in class, record, struct, or interface member declaration [D:\temp\tic\Telerik_UI_for_WPF_Source_2023_3_1114\Core\Controls\Controls_NetCore_5cmyf5ge_wpftmp.csproj::TargetFramework=net7.0-windows]
As I workaround I would suggest editing the NetCoreConfigurations.targets with the following property groups:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug70|AnyCPU' ">
<TargetFrameworks>net7.0-windows</TargetFrameworks>
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<OutputPath>bin\$(Configuration)\</OutputPath>
<DefineConstants>DEBUG;WPF;NETCORE;CODE_ANALYSIS;WPF45;WPF40</DefineConstants>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
<WarningsAsErrors />
<SourceAnalysisTreatErrorsAsWarnings>true</SourceAnalysisTreatErrorsAsWarnings>
<StyleCopEnabled>false</StyleCopEnabled>
<TargetFrameworkVersionString>70</TargetFrameworkVersionString>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug70.NoXaml|AnyCPU' ">
<TargetFrameworks>net7.0-windows</TargetFrameworks>
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<OutputPath>bin\$(Configuration)\</OutputPath>
<DefineConstants>DEBUG;WPF;NETCORE;CODE_ANALYSIS;WPF45;WPF40;NOXAML</DefineConstants>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
<WarningsAsErrors />
<SourceAnalysisTreatErrorsAsWarnings>true</SourceAnalysisTreatErrorsAsWarnings>
<StyleCopEnabled>false</StyleCopEnabled>
<NoXaml>true</NoXaml>
<GenerateImplicitStyles>true</GenerateImplicitStyles>
<TargetFrameworkVersionString>70</TargetFrameworkVersionString>
</PropertyGroup>
The file can be found here: Telerik_UI_for_WPF_Source_[Version]\Build\Imports\NetCoreConfigurations.targets.
Wrong XAML files are shipped with the Net Core themes archive. Instead of Docuemnts.xaml and RichTextBoxUI.xaml the RichTextBox.xaml file should be added.
It is possible for a user to type a value into a RadNumericUpDown control that is greater than the maximum (or smaller than the minimum).
If the control loses focus the value reverts to the maximum value, but in my use case the user will be clicking the OK button on a Window, and this happens while the NumericUpDown still displays the out of range value that was typed. In other words the user doesn't realise that their value was silently rejected behind the scenes.
To solve this I had to raise a support request with you guys, which meant waiting until the next day for a resolution. This cost me time and it also added to your workload.
Whereas if the control had the option to limit the user input to the bounds of minimum and maximum it would have saved me about half a days work to raise a support request and write my own solution to the problem.
I see this has been raised a couple of times in the forums:
https://www.telerik.com/forums/prevent-user-from-typing-beyond-maximum-value
https://www.telerik.com/forums/radnumericupdown-lets-you-type-beyond-its-maximum-value
And the consensus seems to be that it is "By Design".
Please can you re-consider changing this as it is these small niggles that often cost us the most time when developing with 3rd party controls.
TIA
Currently PropertyDefinitions have only one Property for DataBinding, which is very strange solution.
All these instances are DependencyObject, but at the same time they are not in the visual tree and we could not bind to a visibility or to readonly or to any other property without some starnge sorkarounds (why this was designed in this way?).
This makes these objects almost useless. becuae we cannot fully use them in an MVVM way (bindings, multiibindings, etc.)
Possible solutions:
Currently the Windows 11 theme for Telerik WPF features the ability to switch backdrop material to Acrylic, Mica and None, but what it's missing the Mica ALT material.
Because of the substantial difference from the normal Mica material, and the ability it gives to create more modern looking applications we think that the addition of this backdrop material would greatly benefit an already very good looking theme!