Roland Smith's PBSearch utility is the tool to turn to when you need to find a string in your PowerBuilder application. For example, if you have an error message from a bug report, it takes PBSearch only a few seconds to find all the instances of that message. Similarly, if you want to see usage examples for a given function, PBSearch will quickly find and show you the places where that function is called in your application.

As such, PBSearch is analogous to the Object Searcher in the Advanced PowerBuilder Utilities that Sybase used to distribute with PB. PBSearch is much faster, though, and much more versatile - it also does global search-and-replace, helps you find objects among all those PBLs, identifies duplicate and unused objects, and more (read on!).

Roland released PBSearch a year ago and has regularly updated it with new features. The current version already works with PB9! This is no moribund last-release-was-PB6 orphan tool. Roland is very responsive to suggestions, so if there's a feature you'd like to see in the product, send him mail and he may well make it happen. PBDJ editor John Olson, for example, mentioned that he's interested in PBSearch operating at the workspace level, instead of the target level (PB8-speak! - sets of applications), and Roland is pondering how to put that capability into a future release.

Getting Started
The InstallShield setup program will take you smoothly through the usual prompts. When you run PBSearch the first time, it asks which version of PowerBuilder you're running - PB4 through PB9.

That done, you're presented with the main PBSearch screen (see Figure 1).

PBSearch has found the PB.INI file for the specific version of PowerBuilder, identified the application you're working on and the PBLs that make up that application, and presented those PBLs for your searching convenience. The Library Information panel shows the specifics about the PBLs so you can confirm that you're operating on the correct ones. You can switch applications within PBSearch.

Searching Select the PBLs and object types of interest and click the Search button to go to the search screen (see Figure 1).

How fast is the search? If the "Show Line Where Found" checkbox is not checked, the first time it takes PBSearch about four seconds to go through the 1,800+ script objects in my three utility PBLs (30MB of code, 1GHz notebook). PBSearch loads the source into memory that first time, so subsequent searches take about one second. Very fast.

Searches are somewhat slower if you check the "Show Line Where Found" checkbox 10 seconds the first time, six seconds thereafter. Apparently it's slower because it takes time to parse the found line and insert the line into the results DataWindow. Still very fast!

Roland has optimized PBSearch for speed, which means the utility operates on the exported objects as a whole, i.e., it searches the text you'd see if you exported an object in the Library Painter. There's no option to search scripts only (omitting the control attributes, etc.) or just scripts with the comments removed. It's handy to be able to search scripts sans comments when you're on a mission to find all the instances of a particular function call, and don't want to "hit" those places where the function is commented out, for example. Stripping out the comments and object attributes would take a lot of processing time, however, so PBSearch doesn't offer that option.

Replacing
You need to check the "Show Line Where Found" checkbox if you want to do a global replace. Clicking the Replace icon presents the Global Search Replace screen (see Figure 2).

The right side of the display shows the results of the intended search and replace, so you can decide if you really want to make the change. You can't pick and choose. However, if you proceed with the search and replace, all the replacements will be made.

Click the Replace button to proceed with the search and replace. I decided to add "LLC" following each instance of the company name "PowerSmith". It took about two minutes to modify over 600 objects. After that I did a search for "hoyt@PowerSmith LLC.com" and changed that text back to "hoyt@powersmith.com". That replace took one minute.

PBSearch modifies the objects "in place" - the modified object is imported into its original PBL. This is somewhat dangerous; you can mess up your code with a bad search and replace. PBSearch has several mechanisms for preventing that, however.

First, it will warn you if you did not "Match on whole words" during the search, because replacing just part of an identifier would likely produce problems. Second, the utility offers the "Make backups..." checkbox on the replace dialog: if checked, PBSearch copies your PBLs to another directory before operating on them. Third, and most useful, PBSearch allows you to recover gracefully if your search and replace breaks your code (see Figure 3).

Checking the "Restore object..." checkbox tells PBSearch to leave the object unchanged. If the "Terminate..." checkbox is not checked, then you can proceed to search and replace the rest of your objects.

At this point, I'm a believer: PBSearch is truly useful. But wait, there's more, much more.

Advanced Search
This feature allows you to search for more than one string at a time, applying a logical "or" (a "hit" has at least one of the search strings). You can also apply the advanced search to those objects already identified by a previous search, thus applying a logical "and".

Direct Editing
In PBSearch, you can double-click an object reference almost anyplace and be presented with that object's source code in a nicely crafted editor with Find, Search and Replace, Undo, and so on. Thoughtfully, the string from the "current search" is the default when you press control-f to open the Find dialog, so you can quickly get to the string of interest. You can edit the source, then save the object to its original PBL with a control-s; control-w closes the editor window. This is perfect for those situations when you want to do a global search and replace, but the "replace" is more than a simple string - e.g., you're replacing a function with one that has different arguments.

Direct editing does not have the "fail-safe" of the global search-and-replace function when your editing produces bad code. You'll get a compile error when you attempt to save the object, but that invalid code is nonetheless saved. There is no "Restore object to its previous contents" option. On the other hand, you can readily edit code that doesn't compile, which PowerBuilder didn't allow until PB8.

Find Object
For mysterious reasons, PowerBuilder does not provide any mechanism for determining which PBL contains a particular object. With PBSearch's Find Object screen, you can specify a string and it will immediately present you with the objects whose names match that string - with "match" defined as an exact match, as matching the string at the beginning or ending, or as applied in a match()-function grep-like search. The match() function uses the period (.) as a wildcard, but PBSearch helpfully allows you to use asterisks too.

The search result shows the PBLs that contain the objects, so you can easily locate them in PB. The objects in the list can be directly edited, as usual.

Find Object is most useful when you can't quite remember the name of the object. If you know the name and want to edit the object using PB, you would be better off using PB's built-in browser (invoked by clicking the icon): right-click an object and select Edit from the popup menu and PB will open the object in the appropriate painter. To use the PB browser, though, you need to know the object's name; PBSearch can help you figure that out.

DW Query
Suppose you wanted to make sure your DataWindow object's date editmasks are Y2K-compliant, but you only care if the column is visible and can be edited. That means you have to apply more than one logical condition to a search - you need PBSearch! The DW Query tool allows you to build a SQL-like query and apply it to all the DWOs in your application. Roland supplies an example to illustrate the tool. Queries can be saved, and he distributes this query with the application

Duplicate Objects
It's easy for duplicate objects to proliferate in PB applications, and they can present nasty problems. Different developers may see different behavior if they have different library paths. The executable can display mysterious behavior if it was built using a different path than the developers. It's almost always the right policy to prohibit duplicates. PBSearch makes it very easy to find them: select the Reports icon, click the Duplicates icon, and wait about a minute.

PBSearch shows you the objects' size and last-modified date to help you figure out which object is the "keeper" - I'd go with the larger and last modified, and look closely if the last modified is smaller. Direct editing would be helpful here. If Roland gets really ambitious, it would be great to build in a hook to Ken Howe's excellent PBDelta differencing utility (hint, hint).

Unused Objects
Any mature PB application contains an almost inevitable detritus of leftover objects that are no longer used. The Cross Reference utility in the old Advanced PowerBuilder Utilities toolset was one mechanism for getting at unused objects, but only by the painful method of creating the cross-reference and visually examining the results for objects without references. PBSearch makes it easy to identify unused objects.

The process has two phases. Phase one checks "direct object references." There are instances where the object name appears as an attribute of other used objects, e.g., a DataWindow object is a property of a DataWindow control. After phase one, the number of thus-far unreferenced objects is presented, and you're asked if you care to search for indirect references. If so, the phase two search will identify the thus-far unused objects mentioned only in scripts, e.g., DataWindow objects that are assigned programmatically (in code).

Can you trust the Unused Objects report? The usual precaution applies: move the allegedly unused objects to an "obsolete" PBL in case they turn out to be used after all. It would also be nice if the utility offered a "Move these objects" option. Uncharacteristically, the PBSearch output is a mere report, as opposed to the usual double-click-to-edit object list... so you have to print the report and proceed from there.

Search Stored Procedures
PBSearch will also search stored procedures for Oracle, MS SQL Server, and both Sybase databases. It applies the SQL "like" operator to find the string you specify, SELECTing against the source code stored in the database's system tables, which can be time-consuming. PBSearch makes that more efficient, however, by offering the option of looking only at procedures with a specified owner. It would be nice if PBSearch cached the stored procedures in memory, as it does with PB object source, so subsequent searches would be faster.

The result of the stored procedure search is a list of procedures containing the search string; scrolling through the list displays the corresponding procedure.

Figure 4 shows the results of a search for a procedure with "youngest" in the name, perhaps because the developer couldn't remember the exact function name and/or which package contained the function.

The Find Next button moves the focus to the next instance of the search string. Double-clicking any line in the Search Results window opens that procedure in a larger read-only window. You can't edit the stored procedure - yet.

Other Features
PBSearch also provides a report showing how many objects of each type are contained in the application PBLs (how many windows, how many DataWindows, etc.). Another report shows the count of objects by PBL.

The Directory feature presents you with a Library Painter-like interface, where you select a PBL and the corresponding objects are shown in a separate pane. You can double-click any object to edit it directly, as is usual with PBSearch. You can regenerate the entire application's PBLs with two clicks, one to select all the objects and another to start the regenerate! The regen stops with the first failure, unfortunately.

Clicking the IconTray icon minimizes PBSearch and places the PBSearch icon in the icon tray in the lower-right corner of your Windows desktop. The utility is minimized in such a way that you can't alt-tab to it, which is actually helpful. Double-clicking restores PBSearch with its state unchanged - for example, the same screen is showing, etc.

The utility comes with excellent Help. I e-mailed Roland a question about the UI, and was embarrassed later when I found the answer after about two clicks of the Help file.

Getting PBSearch
The utility is available as a free trial download from www.topwizprogramming.com. You get 30 days to try it before the "reminder window" intervenes and delays the open one second for each day beyond the install date. PBSearch costs $60 for an individual license, or $750 for an unlimited site license. In my opinion, it's money well spent.

Roland also has other products. PBSearch is clearly fully ORCA-enabled - ORCA is the mechanism used to import objects into PBLs, regenerate them, and more. You can buy Roland's ORCA tool with a helpful demonstration application. He also has a PSRViewer, which I haven't checked out yet.

Conclusion
PBSearch is a must-buy because it's the fastest way to find strings in your PowerBuilder application and it has a powerful search-and-replace facility. The direct editing feature is exactly what you want if you need to do replacements more complicated than "replace this string with that one," e.g., to replace a function with a different function that takes different arguments. The duplicate and unused object reports are also valuable.

I had some minor problems...but Roland fixed them all! Therefore I say without reservation: PBSearch is a very well-designed, powerful utility that belongs in every PowerBuilder developer's toolbox.

SIDEBAR
TopWiz Software
435 River St.
Castleton, VT 05735
Web: www.topwizprogramming.com
E-Mail: Roland@topwizprogramming.com

• Figure 1
• Figure 2
• Figure 3
• Figure 4