Unternehmen
News
Leistungen
Produkte
Downloads
Suche
Aktuelles


Progress App Dev Challenge

It’s time to show the world (and more importantly your mother!) how good you are building a mobile a...

[mehr]

Premier événement du PUG France

Le club utilisateurs Progress France organise son premier événement dans le bureau de Progress Softw...

[mehr]

Progress OpenEdge Mobile Brings 'Write One, Run Anywhere' To iOS, Android Apps

To help IT keep pace with mounting demands for mobile apps, Progress Software is adding a mobile app...

[mehr]

zum Archiv ->



Consultingwerk Ltd. on LinkedIn Consultingwerk Ltd. 
 

Index > Produkte > WinKit > FAQ  
WinKit - Frequently Asked Questions


Q: Our application is not built on ADM1 or ADM2. Can I use the WinKit with our application?

 

A: Absolutely. The WinKit integrates with your existing application based on knowledge of Progress widgets, regardless of the underlying framework. An underlying framework might make it easier to locate code sections that need to access the WinKit API. But it usually makes no real difference if this framework or template structure was built by Progress Software or you or a third party. We do however have pre-built templates for the WinKit to migrate ADM1 or ADM2 based applications.

 

Q: Our application is not written in the AppBuilder. Can I use the WinKit with our application?

 

A: Absolutely. The WinKit is built to understand relevant parts of the user interface of your application, typically at run time. At this point in time it is usually not important to know how the code that built the user interface was written or generated. For the migration of the origin of the source code may make a difference as we do have two different migration utilities: One is using the AppBuilder API to add the required hooks into AppBuilder based, structured source code. The other set of migration utilities is based on Proparse, an open-source syntax parser for Progress 4GL or ABL code.

 

Q: Our application creates parts of the user interface dynamically. Is that a problem for the WinKit?

 

A: No, that’s not a problem at all. The WinKit does recognize Progress widgets when they appear on the widget tree of ABL windows or frames. Here it makes really no difference if those widgets were created dynamically or static from code. When parts of the application are created dynamically, it might however be another option to modify your rendering code so that it directly instantiates .NET controls with the WinKit and not to build the original ABL widgets first just as an intermediate.

 

Q: How does the migration of our application to the WinKit work?

 

A: After an analysis of your application based on reviewing a number of key screens of different complexity and analyzing the output of code parsing utilities the largest part of the source code migration is performed by our code conversion utilities either based on the AppBuilder API or Proparse, an open-source complex syntax parser for Progress 4GL or ABL code. Sometimes even a combination.

 

Q: Our application uses tables on the user or user group level for dynamically building the menu structure. In what way are we free to keep on using this method and are we free in using and maintaining this structure in WinKit?

 

A: When menu structures either for the application main menu of the menu of each individual application window are stored in database tables or similar repositories like XML files this method can still be maintained for the WinKit. Based on the nature of the existing code that renders the menu structure we simply keep on using this code and convert the generated menu structure using our standard WinKit functionality to either Infragistics Toolbars and Menu structures or a Ribbon control. Based on the nature of your repository data it might also be a good option to modify the existing rendering code to directly generate .NET menu structures or a Ribbon. This may open the existing rendering code to the additional capabilities of the modern .NET Controls such as images on menu items or different types of controls on the menu or toolbar. However when using your existing code and our standard WinKit functionality this additional options can also be used by activating our callback during the generation of the .NET controls.

 

Q: Does Winkit give the possibility to maintain all our programs with the AppBuilder? And if so is this the best way or do you recommend f.e. the OpenEdge Architect?

 

A: Absolutely. Our recommended approach is to continue maintaining the existing application windows in the AppBuilder, either docked into OpenEdge Architect or Progress Developer Studio for OpenEdge (OpenEdge 11) or standalone. For customizing the functionality of the WinKit or writing new or additional modules using mostly object oriented code or GUI for .NET functionality we recommend using the OpenEdge Architect or Progress Developer Studio for OpenEdge as the new development environment provides advanced functionality such as the .NET Visual Designer, the class browser and code completion that simplifies the creation of classes or code that uses classes, objects and .NET Controls. Both tools can be used side by side. Our experience is that in large development teams during the introduction of the new user interface capabilities it is enough that only a couple of developers need to get familiar using the new tools and the rest of the team can continue to work as always.

 

Q: Does Winkit provide source code which we can maintain ourselves or are we bound to support from your side?

 

A: The WinKit is delivered with full source code and the right to perform modification as need to our customers. However when changing the WinKit source code you may be required to merge your changes and ours when we deliver updates.

 

Q: Our application does use Active X Controls. Does the WinKit work with Active X Controls?

 

A: Absolutely. Active X Controls used in the original application do work within the WinKit as well.

 

Q: How does the WinKit help if my Active X Controls do no longer work on OpenEdge 11?

 

Due to changes in the OpenEdge client executable in OpenEdge 11 some Active X Controls might no longer work (on all versions of Windows). See blog.consultingwerk.de/consultingwerkblog/2012/02/issue-with-certain-active-x-controls-in-openedge-11/ for some details. In these cases the WinKit will provide a great starting point for replacing those affected Active X Controls with Controls - .NET Controls do not only provide more modern functionality, look and feel and a better programming model. These Controls are usually also more actively maintained by their vendors. With the WinKit .NET Controls will work seamlessly with your existing OpenEdge GUI application.

 

Q: When we use Winkit does it provide an MDI application or are we free to choose if we want so?

 

A: MDI is an optional feature of the WinKit that can be activated for individual screens or even based on the current user or similar runtime attributes. A personally preferred approach of us is a mix where overview screens are docked as MDI children into the main menu and MDI container form and detail windows are started as individual – non-docked – forms.

 

Similar container features such a dockable panes can also be used as desired.

 

Q: Are there special system upgrades needed for using WinKit?

 

A: The WinKit works with applications on OpenEdge 10.2B and OpenEdge 11. We recommend using OpenEdge 10.2B Service Pack 3 or more recent. The system requirements of the WinKit are those of the GUI for .NET on these versions (.NET framework 3.x for 10.2B and .NET framework 4.0 for 11.0). It is recommended to use the WinKit on top of the OpenEdge UltraControls for .NET. This license needs to be obtained from Progress Software directly.

 

Q: We ourselves use a lot of include files for building dialogs and windows, in what way does WinKit use these?

 

A: Depending on the kind of functionality that is implemented in your include files (like the ON CLOSE OF THIS-PROCEDURE trigger or the WAIT-FOR block) a large part of the WinKit migration can be avoided by placing the WinKit include files inside of your existing include files. This is usually determined during the initial analysis of key application screens.

 

Q: What are the consequences for all our AppServer routines? Does WinKit need special treatment for that?

 

A: No. The WinKit does not modify any business logic, just code that is relevant for interacting with the end user.

 

Q: On what level do developers need to do training for using and maintaining applications which have been converted by WinKit?

 

A: The majority of your developers will only require basic understanding of the WinKit and little to no knowledge of .NET, the GUI for .NET or object oriented programming. Those developers that are participating in the WinKit workshop and should be responsible for maintaining and eventually enhancing or customizing the WinKit functionality in the future should have understanding of the .NET framework, the GUI for .NET, OpenEdge Architect and at least basics of object oriented programming. This knowledge can very often be delivered within one week of training.

 

Q: We have approximately 2000 windows to be converted. How much time do you think we need to convert them?

 

A: This depends on a number of factors. Based on our experience a large percentage of the migration (inserting include files in key locations) can be completed in a few days using our tools. Manual work is only required for exceptions from the rules found during the initial analysis of the application. The more standard functionality is handled by your framework, templates or includefiles the less manual work remains. Applications written using the AppBuilder may require less manual modification than those written in the procedure editor.

 

After having had the chance to review key screens of your application we are usually able to give a good estimate of the amount of manual changes to your code.

 


©2006-2013 Consultingwerk Ltd. info@consultingwerk.de Aktualisiert: 11.02.2012 23:55
   Index   Sitemap   Kontakt   Impressum   Rechtliche Hinweise   TeamViewer   Blog   Wiki