Is there any logic to get the report with powerbuilder object name , size.. As we are migrating the PB project, the other team asking us to generate the above list , as we are lot of objects around 3000, we are unable to do it manually. Please share if there are any way to do the same.
0
votes
4 Answers
2
votes
PBL Peeper (as Seki mentioned) can get you various lists of DataWindows (Seki pointed you to the Reports page, but the List page may also be useful), but you use the word "reports". DataWindows can be used as printed reports, user interfaces, components of both of these, and even non-visual stores (and more). If they are looking for descriptions of printed reports, this will be more complicated. You can use PP to search for Print() or PrintDataWindow() commands (although they may reference function arguments, which will have to be traced back up the call stack, or they may reference controls that may have its DataWindow object reference dynamically modified at run time). Also keep in mind that even once you find the DataWindow objects that are subject to Print commands, DataWindows can also include other DataWindows, so you may have to chain the references (this too can be modified at run time).
You mention "migration". If the intention is to migrate to another technology, keep in mind that DataWindows aren't simple data dumps. DataWindows can leverage embedding, dynamic positioning, data-driven attribute modification and run time modification of just about everything (including run time generation of the entire object); this is the tip of the iceberg when it comes to migrating DataWindows. If someone has a vision of getting the SQL behind the reports, and a few static attributes of the UI elements (e.g. X, Y, width, height), you might do them a service by suggesting there may be more to the task than that.
Good luck.
1
votes
You could use the "print directory" feature that can print the list of objects in a PBL (groupped by object type) with the help of a PDF printer.
If there is a great number of PBLs it could not be very convenient, and PBL Peeper reports might be a better solution.
1
votes
Besides what Seki and Terry mentioned there are other reports in PBL Peeper that would be useful for a team doing migration including Database Column Use and Object Cross Reference. To add to Terry's remarks about the DataWindow, besides the Create and Modify methods there is Evaluate which can execute dynamically created code. Another factor that catches people attempting to move DataWindows to different technology is the PBSELECT, which is the default in DataWindows. At runtime, the Transaction object converts the PBSELECT to SQL for the particular database you're connected to. The PBL Peeper DataWindow SQL report will give you the SQL for the database version you point it to, but unless you run against the exact same database version with the exact same connection settings as the application, it isn't necessarily the SQL the application will generate.
0
votes
Is your project under source control? If so, you could look in the source control folder and run a report off that. Each object gets exported to a text file with extension specific to the object type. Just thinking outside the box here... this might help. I can't think of other ways except get a tool that someone has already written such as peeper the other guys are talking about.
I can pretty much see why someone is asking you this and no matter which method they use it will not be an accurate representation of the application size/objects/code. A datawindow object could have many computed fields in it each like its' own function. There is nothing I know of on the market that will drill into that level of detail. So one dataobject might equal fifty units of programming effort vs. another one might equal one unit of programming effort.
Another issue with using objects to measure code, PB is object oriented so an ancestor object may never be used on its' own. Or a a complex user object might be instantiated in hundreds of places in the application, so counting it as one "unit" is completely misleading. In short, there is no quick and dirty way to measure the effort that went into or would be needed to replace a PB application.
Another simple example, one window doesn't equal one window. One window might have fifty controls instantiated on it, and each of those having code in many events or functions. So one window might equal one unit of programming effort and another might be one hundred units.
Then you have the back-end. How much is being done there. I've been down this road and when management asks for these things they have no idea what they are getting into and they should be warned.
