Migrating Win32 Applications to WPF

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 PowerBuilder