Here: independant comparison between PowerBuilder & EB

I received the following text from an independant developer. Your comments are welcome. Using PowerBuilder when one is used to Eclipse Builder. I have been working with Power Builder for 3 weeks now, I have therefore started making my opinion on the most popular Client/Server development environment at the time (according to the contents of job offers). I will complete this note later, for I know I cannot completely master such a product in so little time. Here is my first reaction: being used to Client/Server and event-driven development, I never thought it would take me so much time to get started with PowerBuilder (honestly speaking, I don't think it took me so much time to get started with Eclipse Builder). I was indeed troubled not to find in PowerBuilder what I was used to in Eclipse Builder: although the same 'modules' exist in both products (database administration, server and client processings...), their concepts make them completely different. PowerBuilder heavily focuses on object-oriented development with all this implies, namely hierarchy, heritage, advantages and drawbacks (the drawbacks are to be found in the difficulty of defining object classes and, mainly, in their maintenance. The advantage is of course the reduction of the source code). The second main problem arises from the fact that the notion of a 'message path' does not exist in PowerBuilder. I thought it was a basic principle of this kind of product... I have therefore had to forget the techniques I knew, and only keep the concepts related to Client/Server and event-driven development, to finally get started. As far as database administration is concerned, there is no surprise: EB and PB offer the same functionalities yet with more security for Power Builder (which is often crippling while developing). For instance, one cannot change the tables' structure as soon as they contain data (columns types, length of char or varchar columns, NOT NULL property...). The only thing one can do is add new columns. Links management is very efficient, but its graphical representation is rather messy. A serious advantage for Eclipse Builder is the notion of 'contexts' (database views) I have not found in PB (unless I have not searched well enough). Another negative aspect of Power Builder: in order to view all the definitions, parameters or properties of an element of the database, one needs to navigate through various windows, many of which are modal. This is really a pain, it is a permanent aspect of this product I will define as not user-friendly at all. To conclude this chapter, I will say the pros are on Eclipse Builder's side. Let's now talk about interface development. Like EB, Power Builder offers during the creation of any new application a 'frame' including a standard menu (File, Edit, Help). Power Builder also creates an MDI (Multi Document Interface) window specific to Windows and a few more objects. We have been advised not to use them, so I didn't try. A big difference compared to Eclipse Builder: an application cannot be divided into various modules or 'projects', to use Eclipse Builder's terminology. Moreover, applications must contain a library located in the same file as the application itself!! One can then add as many libraries as needed. As far as the interface is concerned, Power Builder offers 4 types of objects: menubars, windows, controls (equivalent to EB's 'buttons') and datawindows. The latters handle the link between the database and the graphical interface (see below). The similarity between EB and PB as for windows and controls lies in the fact that the same properties can be modified by scripts. A negative aspect of Power Builder compared to Eclipse Builder: although a window can be declared resizable, the following attributes do not exist: - for windows: minimum and maximum width and height, saving of user changes. - for controls: anchor top, anchor bottom, anchor left and anchor right. If a developer wants to handle these properties, he needs to script them (case of minimum/maximum sizes and anchors) and to save the last coordinates of all windows in a table designed for this or in an '.INI' file. Of course, thanks to the notion of objects' inheritance, it is relatively fast to create the objects and functions needed for the management of such a behavior once and for all. Yet, you have to create them! To the advantage of Power Builder, on the other hand, one can attach any menubar to all windows, create MDI windows, sons of MDIs. Finally (but I may forget some points), one can create 'windows functions' and 'variable instances' which are then features specific to the windows for which they have been declared. As far as other classic objects are concerened, there is no major difference between PB and EB. Except maybe for one, but which is more dependent on Windows: ONE CAN DO ABSOLUTELY ANYTHING WITH THE KEYBOARD EVEN WITHOUT SHORTCUTS; for instance, one can use the tabulation key to give the focus to any kind of control: one then just needs to type <enter> to simulate a click on a button, <space> to change the state of checkboxes, and arrows to change radio arrays. Moreover, <alt> opens the menus which can be operated using the arrows and <alt> + <tab> allows to change the active window. Yet, I do not know whether these functionalities are available in the Macintosh version of Power Builder (yes, I heard a Mac version does exist). I will now talk about a particular object of Power Builder, 'DataWindows'. They allow the application to communicate with the database. They offer, with more possibilities, to do what Eclipse Builder does with its clusters and sql-lists (with or without a cursor). They are actually dynamic data sources. The developer creates queries, with or without parameters, and the viewing of the results in the same object. He will then create in his windows datawindow-type controls and establish a link between the datawindow control and the datawindow object. This link can be modified by script, like the settings of the datawindow objects. The first advantage is of course to ensure a standardized interface. But that's not all: there is no notion of a list in cursor mode or not (PB automatically handles large lists in a way that is transparent for the user or the developer). Possibilities offered to view the data are very numerous (there are of course classic lists and input screens, but also 'grid' or worksheet-type lists, thus a possibility to resize or change the order of columns, all types of graphs, etc...). I have not yet been able to try all the possibilities, but the demo databases are impressive. Yet these DataWindows have a major drawback: although the various controls or buttons can be scripted when they are independent, one cannot script them when they are part of a datawindow. For instance, if one is using input fields, radio arrays or other in a datawindow, it is impossible to attach a script to them. One can only directly script the datawindow controls at the windows' level. To some extent, this amount to writing the equivalent of 4D's 'during-input'-format formulas. Surprising indeed. And not practical at all. These were my first impressions. To conclude on Power Builder, I would say it allows to do anything with