Migrating Win32 Applications to WPF

PowerBuilder

Migration of Existing Applications

Migration: The architecture of WPF is significantly different

The approach to migration will need to be different than Win32=> WinForm

For example, WPF encourages customers to use Styles/Templates to create borders instead of a simple BorderStyle

PowerBuilder

Migration of Existing Applications

If we run into these kinds of conflicts in the WPF runtime library implementation…

We will keep the new WPF style, but…

A migration issue will exist for the developer’s disposition

PowerBuilder

Migration of Existing Applications

More refactoring will be needed than for Windows Forms migration

Some behaviors will change e.g.: MDI applications will be rendered as a Tabbed

document

PowerBuilder

WPF vs. Win32/WinForm

Look and Feel… Some properties / metaphors have no default WPF

equivalent e.g.: BorderStyle, MDI

In a post-PowerBuilder 12.0 time frame… We may create/ship templates to support these “legacy”

styles Look-and-feel can be accomplished through WPF

styles/templates

PowerBuilder

WPF vs. Win32/WinForm

MDI Not supported by WPF

(yet?)

Viewed by Microsoft as legacy with drawbacks

For migrated applications PowerBuilder will convert MDI applications to a

Tabbed Document metaphor

http://karlshifflett.wordpress.com/2008/04/10/wpf-sample-series-wpf-mdi-task-switching/

PowerBuilder

WPF vs. Win32/WinForm

User Defined Custom Events WPF - the event model is changed Several custom events have no WPF matching event Will not be supported in PowerBuilder 12.0

PowerBuilder

WPF vs. Win32/WinForm

Window Handle Usage:

Win32/WinForm applications Each control is actually a Window

Each control has its own Window handle

e.g: You can call SetParent(hwnd) to set the parent Window for the current Window through Win32 API calls.

…cont’d…

PowerBuilder

WPF vs. Win32/WinForm

…cont’d…Window Handle Usage:

In WPF, there is only a single handle for the Window

A control nested in a Window will NOT have its own handle

API calls using Window handles will not be supported

For migrated applications, there is no workaround but to refactor the code

PowerBuilder

WPF vs. Win32/WinForm

Event Sequence: Again, the event model of WPF application is changed

The event sequence of WPF applications is different than WinForm / Win32

We cannot ensure the event sequence of WPF controls is exactly the same

For migrated applications, there is no workaround but to refactor the code

PowerBuilder

Fully Managed Code at Runtime

.NET applications deployed by PowerBuilder 11.x have a Managed Code runtime…except for the DataWindow engine

Current PowerBuilder 11.x “Unmanaged” issues: Need to specify the path for DataWindow unmanaged DLLs Can not run applications in partial trust environments

The DataWindow engine is being rewritten from the ground up in C# and will be fully-Managed Code