New V11 Charting Features for .NET (WinUI, WPF, Winforms), MFC, VCL, ActiveX

I. Improvements Overview:

This is no lightweight upgrade. Version 11 more than doubled the size of ProEssentials - a full new WinUI interface, compounded by .NET 10, compounded by a native ARM64 engine.  

Version 11 is primarily a platform, interface, and user-experience release. Where past major versions focused on new chart properties and rendering engines (including v10's GPU-side ComputeShaders expansion), v11 broadens where ProEssentials runs and modernizes how end users interact with a chart at run time.

The main headline additions are: 

• New WinUI 3 interface;
• New native ARM64 support across the .NET 10, .NET 8, and .NET 48 interfaces (.NET 48 AnyCPU covers x64, x86, and ARM64 from one build);
• New .NET 10 interfaces across WinUI, WPF, and Winforms;
• New modern built-in .NET-centric menu and dialog UX (with improved WYSIWYG image export and print dialogs) across all the .NET interfaces, plus built-in localization in 19 languages with no satellite assemblies;
• New improved TestBed - export any individual demo example as its own standalone, ready-to-build starter project, so you begin from working code instead of a blank page;
• Under the hood, modernized native-engine loading and improved .NET interfaces that create less friction moving from eval to retail DLLs.

What ties these additions together is what stays the same underneath. Every ProEssentials interface - from the original Win32 DLL through the ActiveX controls, Windows Forms, WPF, and now WinUI - is a thin interface over one mature, native charting engine that Gigasoft has refined for decades. v11 is largely the work of bringing that same engine to new places: a native ARM64 build of the engine, a WinUI interface that hosts it through Direct3D and Direct2D composition, new .NET 10 targets, and a single .NET Framework AnyCPU build that runs native on x64, x86, and ARM64 alike. Because the engine itself is proven and unchanged, this added reach costs nothing in stability or rendering performance - and your existing Pexxx code carries across interfaces with little more than a control type-name change.  
 

If upgrading, most existing code continues unchanged.

As always your feedback is greatly appreciated. If you have a specific use-case needing attention, let us know. If you need a current feature fixed or tweaked, let us know. If you need a new feature, let us know.

PRO TIP: We can not stress enough, the best resource to "find a property, method, event" is by typing plain English words in our website's API explorer search box:  https://gigasoft.com/documentation  It's powered by the same PE-Query engine your AI assistant can use.

II. New WinUI 3 Interface:

Delivering a native charting interface for each generation of the Windows UI has been Gigasoft's focus for 30 years, from the original Win32 DLL and the VBX for Visual Basic 1, to the ActiveX (OCX) controls, to .NET Windows Forms, then WPF, and now the modern WinUI 3. Version 11 adds Gigasoft.ProEssentialsWinUI, a first-class .NET interface joining Winforms and WPF.

Microsoft advertises WinUI as the  new modern "native" interface moving forward.  And ProEssentials' WinUI interface is truly the most "native" "native" interface backed by native Direct3D plus Direct2D C++ based binaries. Across every .NET interface, the ProEssentials charting and rendering engine is native, pre-compiled C++ built on Direct3D and Direct2D; the .NET layer is only a thin managed wrapper over it. The CLR therefore never JIT-compiles a huge managed charting engine - only the lightweight wrapper is JIT'd, at negligible cost - and at load time ProEssentials binds the architecture-correct native engine (x64, x86, or ARM64) for full native rendering performance on each. This architecture has delivered native-speed charting for over twenty years, while much of the industry rewrote their engines in fully managed C# and absorbed the JIT and throughput cost that comes with it.

For 30 years, Gigasoft has always been dedicated to native-built charting, and greatly appreciates Microsoft re-committing itself to the future of native. 

WinUI is also the long-overdue modernization of WPF, whose visual layer has remained tied to the now-ancient DirectX 9. The WinUI control instead renders through modern Direct3D and Direct2D composition swap chains hosted directly in the XAML visual tree, and exposes the same Pexxx property, method, and event API you already use in the other interfaces, so porting example code between interfaces remains straightforward.

The WinUI control targets .NET 10 (WindowsAppSDK) and ships as a single control DLL with every supported language embedded (no satellite assemblies). It supports the same chart types and the new built-in UX described below. See Chapter 2 WinUI Walkthrough for a step-by-step getting-started example.

One thing to know up front: WinUI deployment is heavier than WPF or WinForms. Because WinUI depends on the Windows App SDK, a deployed app needs two runtimes on the target machine - the .NET 10 Desktop Runtime and the Windows App SDK Runtime - or you publish it self-contained so both runtimes travel inside the app folder and nothing needs to be installed. Also remember that a .NET app is a launcher exe plus its DLL and JSON config files, so you deploy the whole output folder, not a single exe. Our setup installs these runtimes for the demos, and .NET Deployment covers both models in full - it is worth reading before you ship a WinUI app.  If you've installed VS2026, you are ready for our WinUI interfaces.

One related tip worth knowing early: in your own WinUI project, reference the Microsoft.WindowsAppSDK.WinUI and Microsoft.WindowsAppSDK.Runtime component packages rather than the all-in-one Microsoft.WindowsAppSDK umbrella package. The umbrella transitively pulls the Windows AI / ML / ONNX runtime into your output - roughly 40 MB across a dozen extra DLLs, including DirectML.dll and onnxruntime.dll - that your application likely never uses. 

III. Native ARM64 Support:

Version 11 introduces a native ARM64 engine, PEGRPARM64I.DLL, and ARM64 control flavors for the Winform and WPF interfaces on .NET 48, .NET 8, and .NET 10, and for the WinUI interface on .NET 10, together with ARM64 NuGet packages. ProEssentials now renders natively on ARM64 Windows devices, including embedded scenarios and native ARM64 development within Visual Studio.

On an ARM64 machine, native ARM64 processes load PEGRPARM64I.DLL, while x64-emulated processes continue to use PEGRP64I.DLL; the two distinctly named engines coexist so each application loads the engine matching its architecture. See Chapter 5 for DLL deployment details including PEGRPARM64I.DLL.

IV. .NET 10 Support:

All .NET interfaces (WinUI, WPF, Winforms) add a .NET 10 target, with .NET 10 NuGet packages and demo projects. The installed demos now include .NET 10 WinUI, WPF, and Winforms example folders in addition to the existing .NET Framework 4.8 and .NET 8 demos.

V. .NET Framework (net48): One Build for x64 + x86 + ARM64

The .NET Framework interface is the one that deploys to every Windows architecture from a single build. Because a .NET Framework AnyCPU assembly is pure IL rather than an architecture-fixed launcher, one compile runs natively as x64, x86, or ARM64 - so a single EXE and a single installer cover all three, with ARM64 selected through the project's Prefer native ARM64 option (.NET Framework 4.8.1). This AnyCPU flavor embeds all three native engines and binds the one matching the running process. v11 also ships explicit x64, x86, and ARM64 flavors that bind the real engine name (PEGRP64I.DLL / PEGRP32I.DLL / PEGRPARM64I.DLL) when you prefer a single-architecture build.

The modern .NET (Core) interfaces behave differently: a .NET 8 or .NET 10 AnyCPU build produces a native launcher whose architecture is fixed at build time, so an x64 build runs x64-emulated - not native - on ARM64. This is standard .NET 5+ behavior, not specific to ProEssentials, so for those interfaces we recommend building and installing a per-architecture EXE (x64 and ARM64). They still offer self-contained AnyCPU packages: the .NET 8 AnyCPU embeds x64, x86, and ARM64 engines, while .NET 10 AnyCPU embeds x64 and ARM64 - so if you need x86 inside an AnyCPU package, choose the .NET 48 or .NET 8 flavor. See .NET Deployment for the full deployment matrix.

VI. Modern Native Loading and Unified Licensing:

Version 11 retires most of the long-standing AnyCpu practice of renaming the native engine to a single generic name (.NET 4.8 required this pattern). Instead, .NET8 and .NET10 use a runtime resolver to bind the engine reference to the real architecture-specific engine (PEGRP64I.DLL, PEGRPARM64I.DLL, or PEGRP32I.DLL) using the normal operating-system search order.

For the self-contained AnyCPU flavors, the embedded engine is unpacked beside your application EXE when that folder is writable (the common case), and otherwise to a per-user cache at %LOCALAPPDATA%\<brand>\ProEssentials\<version>\<arch>\. The cache brand is taken from the new PeGlobal.CacheBrand property, else your application's AssemblyCompany, else "Gigasoft". Because the native engine self-reports its license state (a stamped engine is licensed, an unstamped engine runs in evaluation with a watermark), the same assemblies work for evaluation, development, and distribution without swapping files.

VII. New Built-in User Experience (Menu and Dialogs):

Version 11 adds a modern built-in user interface for the WinUI and WPF controls, and modernizes the Winform control's UX. This includes a native right-click context menu and a set of modern, resizable dialogs: Color, Font, Export (with live preview and a font-size slider), Print (with live preview plus printer, orientation, copies, style, and DPI selection), Text Export, and a new Titles dialog.

Every installed .NET demo, from .NET 10 down to .NET Framework 4.8, opens with this new popup menu and dialog UX by default, so you can explore it immediately. If you prefer the legacy Win32-based menu and dialogs, set the control's UseWinformsUX (Winform), UseWpfUX (WPF), or UseWinUIUX (WinUI) property to false.

The entire UX is fully localized. All 19 supported languages are embedded directly in the single control DLL, so there are no satellite assemblies or culture subfolders to distribute.

VIII. New Properties:

Version 11 adds only a handful of new properties. They are discussed in detail here so you can adopt them without waiting on the individual reference pages; the full alphabetic Property, Method, and Event listing remains the authoritative reference for everything else.

RenderPriority (WinUI): Controls how the WinUI control schedules its Direct3D/Direct2D render work, with values Auto, Low, Normal, and High. Auto (the default) keeps the interface responsive during interaction while protecting modal dialogs from render starvation; choose a fixed priority only when you need to override that balance. It is read at each render request, so it can be changed at any time, even mid-interaction.

PeGlobal.CacheBrand (static string, AnyCPU flavor): Names the per-user folder used when a self-contained AnyCPU assembly must extract its embedded engine because the application folder is not writable. The path is %LOCALAPPDATA%\<CacheBrand>\ProEssentials\<version>\<arch>\. Leave it unset and the brand defaults to your application's AssemblyCompany, or "Gigasoft" when that is empty. Set it once at startup, before creating any chart. If you would rather not rely on the cache at all, explicitly deploy the real engine next to your application (PEGRP64I.DLL, or whichever engine your setup needs); the resolver loads it directly and the %LOCALAPPDATA% extraction logic never runs. It is ignored by the architecture-specific x64, x86, and ARM64 flavors, which never extract an engine.

UseWinformsUX / UseWpfUX / UseWinUIUX (bool, default true): Enable the new built-in menu and dialog UX described in section VII. Set the property for your interface to false to fall back to the legacy Win32 popup menu and dialogs.

PeAnnotation.EnableWinUIDrawTable (WinUI, bool): Opts the WinUI control into a dedicated composition layer for real-time table annotations (PEdrawtable), so table overlays update efficiently without forcing a full re-render. Examples 028 and 030 demonstrate PEdrawtable in this mode.

Localized date-axis strings: A set of engine strings that let the control render fully localized date axes, covering three-character month names, three-character and one-character day names, and the date separator character. The .NET controls apply these automatically as part of their localization, and they are also available to native (DLL/OCX/VCL) developers.

IX. Localization:

The .NET control DLLs are single-file and embed all 19 languages, eliminating satellite resource assemblies. The native engine renders localized date-axis month and day labels and separators, so localized date axes are handled end to end.

The legacy v10 localization mechanism remains fully supported as well. MFC/C++ DLL, Delphi/Builder, and even .NET developers can continue to rely on the engine loading a separate resource-only DLL, as described on our resource files page at https://gigasoft.com/resourcefiles.

X. New Demo Examples and New WinUI printing example:

Version 11's demo additions center on the new interface and target frameworks. The installer adds a WinUI demo project in the WINUI-C#.NET10 folder, .NET 10 editions of the Winform and WPF demos in the C#.NET10 and WPF-C#.NET10 folders, and WinUI editions of the high-performance flagship demos in the GigaPrime2DwinUI and GigaPrime3DwinUI folders. These sit alongside the existing .NET Framework 4.8 and .NET 8 demo folders, so you can compare the same charts across every supported interface and framework.

Note the WinUI examples include a new WinUI printing example project that demonstrates WinUI's improved printing features.  WPF's printing support was always lacking and/or very tedious to implement print preview. Now WinUI's printing easily supports print preview, a great addition to your WinUI-based software.  

XI. New to ProEssentials?

If you are evaluating ProEssentials for the first time, the New V10 Features and New V9 Features topics are also worth a skim, along with the matching news pages at https://gigasoft.com/proessentials10news and https://gigasoft.com/proessentials9news. Much of what those releases introduced remains central to the product today.