Migrating Win32 Applications to WPF by bzs12927

VIEWS: 301 PAGES: 11

									Migrating Win32 Applications to WPF
Migration of Existing Applications

  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

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

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

WPF vs. Win32/WinForm

  Look and Feel…
    Some properties / metaphors have no default WPF
       e.g.: BorderStyle, MDI

  In a post-PowerBuilder 12.0 time frame…
    We may create/ship templates to support these “legacy”
    Look-and-feel can be accomplished through WPF

WPF vs. Win32/WinForm

   Not supported by WPF

   Viewed by Microsoft as
    legacy with drawbacks

   For migrated applications
    PowerBuilder will convert
    MDI applications to a
   Tabbed Document

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

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.


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

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

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


To top