1. Migrating Win32 Applications to WPF

2. 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

3. 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

4. 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

5. 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

6. 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/

7. 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

8. 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…

9. 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

10. 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

11. 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