This chapter provides a complete .NET Charting overview of the ProEssentials product. It includes info for the WinUI, WPF, Winforms and WebForm interfaces for use with Visual Studio.  

Developers will use the WinUI, WPF or Winforms interfaces when creating stand-alone client side EXEs.  Developers will use the WebForm interfaces within ASP.NET web applications.

WinUI assembly "Gigasoft.ProEssentialsWinUI.Dll" offers namespaces:

New development? Start with WinUI. WinUI 3 is Microsoft's current-generation Windows UI platform and the modern successor to WPF, whose visual layer remains tied to the now-ancient DirectX 9. Our WinUI interface renders through Direct3D and Direct2D composition swap chains hosted directly in the XAML visual tree, targets .NET 10, and carries the new built-in menu and dialog UX. WPF and Winforms remain fully supported and are the right choice for an existing application - but for new work, WinUI is where we recommend you begin. See New V11 Features for the full WinUI story.

In XAML, reference the WinUI namespace with xmlns:pe="using:Gigasoft.ProEssentials".

A note on control type names. Every .NET interface shares the one namespace Gigasoft.ProEssentials, so each interface after our original Winform interface gives its control types a matching suffix: the Winform types are Pego, Pesgo ...; the WPF types are PegoWpf, PesgoWpf ...; the WinUI types are PegoWinUI, PesgoWinUI ...; and the WebForm types are PegoWeb, PesgoWeb ... . All of them expose the same PExxx property, method, and event API, so example code ports between interfaces with little more than a type-name change.

WPF assembly "Gigasoft.ProEssentialsWpf.Dll" offers namespaces:

WinForms assembly "Gigasoft.ProEssentials.Dll" offers namespaces:

WPF vs WinForm Development

The WPF interfaces have a WPF specific property RenderSizeXdpi.This controls if a non-96 dpi system compensates for dpi by multiplying RenderSize by dpi factor. True by default, font sizes and line thicknesses will not scale on non-96dpi systems. Instead, image sharpness is maintained rather than allowing lines and text to become fuzzy. You may prefer to change this setting to False if you prefer the chart to become fuzzy if the system has larger than normal fonts, possibly to match other fuzzy graphics within the app.

WebForm assembly "Gigasoft.ProEssentialsWeb.Dll" offers namespaces:

ProEssentials installs several assemblies providing options for building and deploying your applications. These assemblies are found in folders,
Nuget
DotNet10
DotNet80
DotNet48

Each folder also contains a readme file.

We recommend the x64 assemblies for desktop development.

Our AnyCpu assemblies embed our native engines within the assembly and are therefore larger. On .NET 8 and .NET 10, the assembly unpacks the engine matching the running process on first run - beside your EXE when that folder is writable, otherwise to a per-user cache under %LOCALAPPDATA% - so nothing extra needs to be distributed.

Our architecture-specific assemblies reference the native engine by its real name, so they are smaller and make the run time requirement explicit. Our x64 assemblies require the project Platform Target to be set to x64 and PEGRP64I.DLL be distributed with your EXE; our ARM64 assemblies require PEGRPARM64I.DLL; and our DotNet48\x86 assemblies require the project Platform Target to be set to x86 and PEGRP32I.DLL be distributed with your EXE. The .NET Framework 4.8 AnyCpu flavor is a special case: because a .NET Framework AnyCpu executable is architecture-neutral, a single 4.8 AnyCpu build runs native as x86, x64, and (with the "Prefer native ARM64" option) ARM64 - the only flavor in the product that delivers all three architectures from one build.

This difference matters for how you ship an application that must run native on ARM64. With .NET Framework 4.8 AnyCpu the answer is the simplest one possible: build once, ship one EXE, and use one installer - the same executable runs native on x86, x64, and ARM64, so your setup needs no architecture detection.

.NET 8 and .NET 10 behave differently, and this is a property of .NET itself - true of any executable built for .NET 5 or later, not something specific to ProEssentials. A .NET (Core) executable has a small native launcher whose architecture is set when you BUILD it (the standard PlatformTarget behavior; see Microsoft's C# compiler output-options documentation). An "AnyCpu" .NET project still produces a launcher matching your build machine - x64 on an x64 machine - and that choice is fixed; it does not adapt at run time, so on an ARM64 device it runs under x64 emulation rather than native ARM64. To give ARM64 users native performance you build a separate ARM64 executable in addition to the x64 one, and your installer detects the running architecture and installs the matching EXE (or you publish a self-contained per-architecture build).

Note the distinction between the executable and the referenced control assembly: only the EXE's target architecture needs to be ARM64. Your ARM64 executable can still reference our AnyCpu control assembly - the control assembly stays AnyCpu and unpacks the ARM64 engine because the hosting process is ARM64. In short: .NET 4.8 AnyCpu is one build, one installer; .NET 8/10 native ARM64 is a two-build, architecture-aware install, and either way our control assembly can remain AnyCpu.

See .NET Deployment for the full per-interface matrix, ARM64 notes, and the additional runtime requirements of a WinUI application.

It's recommended you keep this help system open while working with ProEssentials to quicken access to reference materials.  Please note we've taken these steps to aid in your current development: there's embedded XML help/intellisense;  (most everything ProEssentials starts with "Pe"); and we've chosen an object model API which is primarily oriented as nested properties and does not force a large understanding of .NET ideologies to be immediately productive.

Please refer to the ReadMe files, Demo, and Example Projects for additional .NET resources.

Object Model

Intellisense technology will automatically pop up help as needed while you're programming. Our .NET interfaces use nested properties that break up our 1000+ features among 12 main categories. When Intellisense pops up for auto-code completion, you'll see ProEssentials features starting with letters "Pe". This groups them within Intellisense's list box for easier navigation.

The categories are as follows:

Also grouped within Intellisense's list box are our events that also start with "Pe".

Within the property reference material, at the top of each property topic, you'll see a table with various property attributes.  For example, the property FontSize has such an entry.

If developing with either WPF, WinForms or WebForms, you'll refer to this property via the .NET row heading.

For a control named Pego1, to programmatically control the FontSize property within code, you'll write...

It is recommended that the namespace: Gigasoft.ProEssentials.Enums be included at the top of your source code files utilizing ProEssentials. In VB.NET, use the Imports keyword, and within C#, use the using keyword. For example:

Imports Gigasoft.ProEssentials.Enums
or
using Gigasoft.ProEssentials.Enums;

Designer Notes

The WinForm interfaces support adapting to changes in the parent form's font and background color. They are designed so that the grid number text size matches that of the other standard controls such as TextBox, Radio Button, and Labels. As long as you don't explicitly change the font and background color, you will be able to change the form's font size and backcolor and all controls on the form will adapt to match. This feature required that we defaulted the properties PeFont.SizeGlobalCntl to .85 and PeFont.Fixed = True. Note that the default form text size of 8 points is fairly small. You may want to increase it to 9 or 10 points depending on your needs. This feature results in a clean looking user interface where the charting control appears to be a true sibling of the other standard controls.

WebForm vs WinForm Development

The WebForm and WinForm interfaces are very similar, but they do differ in a few events and properties.  This is best outlined within the ASP.NET walkthrough content.  Generally, the only events available have to do with adding imagemap details.  Also, there's a few additional properties to control how content is dynamically rendered.  The WinForm interfaces have many properties related to user interface characteristics.  The WebForms contain these properties only in the event you are rending an ActiveX binary state to be streamed to the browser.  This allows a ProEssentials ActiveX control to be instantiated with the specific user interface desired. Event processing is still handled via ActiveX event processing as described in the ASP Readme file installed with the product.  ProEssentials only supports rending images and ActiveX content via binary streaming.  This is the only mechanism that supports WebFarms efficiently. Passing viewstate back and forth is not good web design for complex objects containing lots of data.  If our competition supports this feature, they also warn against using it as it's not recommended. Due to the high inefficiency, we don't offer a feature to pass viewstate back and forth.