1. Your building blocks for fast and future-proof development Koen Verbeeck Senior R&D Engineer koen.verbeeck@binteq.com Evy De Block R&D Engineer evy.deblock@binteq.com

2. Located in Puurs, Belgium Unique team of Progress OpenEdge Developers – Each member having +15 years Progress OpenEdge experience Focus on: – Development Frameworks (Desktop, Mobile, Web) – Migration Strategies – Enterprise ERP Solutions Serving World-wide customer base – Each having unique requirements About BinteQ

3. Grown up using Progress OpenEdge Made the switch of: – “Framework user” (Financial applications)  – “Framework Developer” (technical scope) Internal Nick-name is “Sherlock” – Because of her unique “in depth” research & debugging techniques Worked with Progress OpenEdge on: – Windows, – Unix, – … About Evy De Block

4. Long history with Progress Development – Since 1987 – Progress version 4.2 (first release using “overlay frames”… ) Worked with Progress OpenEdge on any possible platform – Windows, Unix, VAX/VMS, OS/400, Motif, … Specialized in Development Frameworks for Progress: – Windows Desktop Applications – Mobile Apps – Web Development About Koen Verbeeck

5. ①Progress Evolution & Partner Reality ②Principles ③Classic ABL vs OO ABL ④Our goals & approach ⑤Demo’s ⑥Summary ⑦Q&A Agenda

6. 1. Progress (R) Evolution Since OpenEdge 10.x (and continued in OpenEdge 11.x): Object Oriented Programming (OO ABL) Support for Modern.Net Controls (GUI for.Net) Visual Designer ProDataSets Structured error handling 32/64 bit support IPv6 New SOAP parser …

7. Progress OpenEdge Partner Reality Existing Progress applications since Progress v4, v5, v6, v7, … Mature and Rich applications Decades of man-years of work Huge investment for full-rebuild (not feasible) Technology: Client Server applications, extensive use of: Full procedural code Includes Shared Variables ActiveX Controls to spice up UI ….  Does this sound familiar ?  How to deal with this ?

8. Why Modernize ? Business reasons: Safeguard Competitive Market Position Safeguard application value Technical reasons: (R)Evolution won’t stop Need to motivate young talented developers o Require Modern Development Studio o Object Orientation is a must, procedural is “weird” Interface with modern external systems Support new OS’s …

9. Make Legacy Applications OpenEdge 11 ready – Use Visual Designer – Use OO ABL, DotNet Controls, … – Modern Look & Feel Foundation for New Applications using New Technology Improve performance Migration for existing applications: – Re-use Application Layouts – Replace ActiveX Controls with DotNet Controls – Code level compatibility for current applications Our Goals

10. Manufacturing Principles Learn and explore new OO ABL Design & write new Components Redesign & rewrite framework (1 time effort, done now) Design & optimize Conversion Tool Convert application(s) Our approach

11. Design process – Raw materials – Design Manufacturing process – Components – Standards – Quality Control Distribution / Deployment Customer Care 2. Manufacturing Principles  Is software development any different ?

12. Requirements Predictable Time Predictable Quality Predictable Cost Software Development Fly2Pro  This is what Fly2Pro is all about ! Application Developers (focus on what to build, not how to build it) Framework Developers (R&D, search how things work)  Different Type of Software Engineers

13. Classic ABLOO ABL / GUI for DotNet Programs (.w &.p) Classes (.cls) Procedures & Functions Methods, Events, Properties Windows Frames Widgets Control Frames OCX Controls DotNet Forms DotNet Controls (Infragistics & MS) App Builder Visual Designer … … (Different Worlds) 3. Classic ABL vs OO ABL (Different Worlds)

14. ABL Windows & Frames cannot “contain” DotNet Controls  only DotNet Forms can host DotNet Controls DotNet controls cannot simply “replace” OCX Controls  OCX controls reside in the widget chain: ABL Window Control Frame OCX Control  DotNet Controls reside in the DotNet object chain DotNet Form DotNet Control What is NOT possible

15. Use object-oriented ABL to access.NET objects Data binding between ABL data sources and.NET controls Write ABL event handlers for.NET controls Embed “ABL Windows” into DotNet “WindowContainer” Concrete: – Classic ABL (.w &.p) can access Methods in OO ABL Classes (.cls) – Classic ABL procedures can “subscribe” to DotNet Events – Embedding explained Integration Possibilities

16. Re-use Layouts: Window Embedding ABL Window OCX Control ABL Frame & Widgets DotNet Form WindowContainer

17. Results  Both ABL Program.w as well as DotNet Form.cls are active in memory  ABL Window is no longer visible, only frame(s) + widgets  ABL Window still exists (hidden / view still has effect)  ABL Window is embedded into WindowContainer Control on.Net Form Window Embedding ABL.w DotNet Form  Correct “destroy / dispose” order of both is essential !!!

18. ABL User Controls Embed native DotNet Controls in ABL User Controls – To be used in “new” DotNet framework – UI only, no data access – Full OO ABL using Visual Designer – Standerdize 1.000’s of properties – Hide Control complexity for Application Developer – Open for future change Infragistics Ultra Controls Telerik RAD Controls Other… Design New User Controls

19. Essential Controls: Grid Control Command Bar / Ribbon Bar Tabstrip Control Modern & More advanced Controls: Scheduler / Calendar Control Docking Pane Manager Control Property Grid Control Charting Controls …. ABL User Controls

20. Re-design framework – Split UI & Logic – Migrate Logic to OO classes – Invoke new DotNet User Controls – Slim down legacy framework Keys to success – New controls don’t overlay existing controls – No double UI code to execute Integrate Old & New World  Faster application performance !!!

21. Co-existence of Classic ABL & OO ABL (New Code)

22. Controllers – Data Access for UI Components, pass results in Temp-tables – OO ABL – Can execute Local or on AppServer Proxies – Instantiation of Controller (local or AppServer) Examples – CommandBarController(data access to build Menubar/Toolbar) – SecurityController(data access for security etc) – MenuShellController(data access for Menu Shell) – MenuShellProxy – SecurityProxy New framework objects (besides User Controls)

23. Clean integration using Published Events Classic ABL.w Classic ABL.w DotNet Form Embedwd ABL Window DotNet Control WAIT-FOR System.Windows.Forms.Application:Run(mainForm). Fire Events Fire Events Subscribe Grid Ctrl Grid Ctrl Publish Event

24. Time to show something

25. 5. Real Life example  Ribbon Bar  Grid Controls  Docking Panes  ButtonBar Controls  TabStrip Controls  Split Container  Legacy ABL Frames

26. More examples: Scheduler / Calendar  Ribbon Bar  MultiView Calendar Control  Docking Panes  Legacy ABL Frames

27. new application First impression of your “new application” – Showcase for new DotNet UI Completely new UI Code – Visual Designer – OO ABL Modern interface: – MDI Interface: fast switching, organized desktop – TileView – Round buttons – Dockable Favorites-, Recently Used-, All Programs panes – Locate programs using Search Menu Shell

28. Menu Shell Showtime

29. Tile Menu Shell

30. Automated Migration ConvOE11 Tool can be customized / extended ConvOE11 Tool can handle most (+90%) of the programs Progress Browsers automatically converted to DotNet Grids Some “special programs” will require manual attention Real Life statistics Migrated Enterprise class ERP application (now Intl. deployed) + 4.000 programs, +2.000 forms about 3 months Migrated several partner applications as well in very short time Short Term Migration Fly2Pro  Thanks to Fly2Pro, R&D has been done !!!

31. Compatibility as far as it can go New modern technology OO ABL DotNet OE11 Future proof for new platforms Modern UI Modern Grids Ribbon Bar (or any other commandbar) Open for any.Net control (e.g. advanced planning boards) Short Term Migration ConvOE11: Manual labor can’t beat automated processes 6. Summary Fly2Pro

32. Short Term Migration ConvOE11: Manual labor can’t beat automated processes Create New applications faster With consistent quality thanks to the well designed components Soft learning curve for developers Designed to let ABL developers make the OO step “easy” Improved application performance We’ve seen the difference Predictable time, cost and quality We’ve learned from the manufacturing principles 6. Benefits Fly2Pro

33. 7. Any Questions ?