1 / 11

Migrating Win32 Applications to WPF

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

radwan
Download Presentation

Migrating Win32 Applications to WPF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Migrating Win32 Applications to WPF

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

More Related