Normally when you use OLEObject to connect to an ActiveX control and encounter an error, you will get the generic run time error ‘R0035 – Application terminated. Error calling external object function xxx’.

I have run across a very simple way to capture the actual error code and message generated by the ActiveX control.

First, create a new Standard Class object and select oleobject for the type.

Next add the following instance variables:

ULong ErrorCode

String ErrorText

Then add this code to the externalexception event:

ErrorCode = ResultCode

ErrorText = Description

Finally save the object as n_oleobject.

Recently someone asked me how they could get the output from PBDOM used from a PowerBuilder Classic Win32 application formatted with white space as PBDOM doesn’t include it.  I gave them a number of options, particularly MSXML through OLE Automation or using a .Net class like XmlTextWriter.  Normally if you were going to try to access a .Net assembly from a PowerBuilder Classic Win32 application, you would do it via a COM Callable Wrapper.  However, for something this simple I thought there had to be a more lightweight way to accomplish it.  One particular lighterweight way that occurred to be would be to have the application launch a Windows PowerShell script that would then use the .Net class in question.  We’re going to look at an example of how that’s done.

The first thing we’ll need is the PowerShell script to do the work. This is what I came up with (referenced as prettyprint.ps1 in the later code):

param( [string]$filein, [string]$fileout ) [void][System.Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq") [System.Xml.Linq.XDocument]::Load($filein).Save($fileout) # If running in the console, wait for input before closing. if ($Host.Name -eq "ConsoleHost") { Write-Host "Press any key to continue..." $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp") > $null }

The script declares a couple of parameters (the input xml file and the output xml file).  It then loads the System.Xml.Linq .Net assembly via reflection.  Finally, we load the file and then write it back out again with white space.  The last few lines are just for debugging from a command line prompt, as it displays a “Press any key to continue…” prompt before closing the PowerShell process window.

To test it through a batch file, I used this:

@ECHO OFF SET ThisScriptsDirectory=%~dp0 SET PowerShellScriptPath=%ThisScriptsDirectory%prettyprint.ps1 SET SourceFile=%ThisScriptsDirectory%config.xml SET DestFile=%ThisScriptsDirectory%.config.new.xml %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' -filein '%SourceFile%' -fileout '%DestFile%'"; pause

The assumption here is that the batch file, the PowerShell script and the input xml file are all in the same directory.  I’ve got a pause statement in this script, so you actually get two “Press any key to continue…” prompts.  If it works properly, that’s all you should see.  Otherwise you should see the error message from PowerShell or the batch file.

ImageMagick is a free open-source software package that allows you to convert image files between formats, resize images and perform other functions. It can be used from the command line or as a COM object using PowerBuilder’s OLEObject functionality.

You can download the installer from here: http://www.imagemagick.org/script/binary-releases.php#windows

You must use one of the installers with the word “dynamic” in the description. I chose the Win32 installer because it offers a higher resolution than the Win64 Dynamic installer.

The command documentation for ImageMagick can be found here: http://www.imagemagick.org/script/command-line-tools.php

There are several commands that are supported by the COM interface.

compare: Compares two image files and returns information about the differences.

composite: Overlaps one image over another resulting in a third image file.

convert: Converts between image formats as well as resizing the image and other actions such as blur, crop, despeckle, and much more.

identify: Describes the format and characteristics of image files.

mogrify: Resizes the image and other actions such as blur, crop, despeckle, and much more. Mogrify overwrites the original image file, whereas, convert writes to a different image file.

montage: Creates a composite image by combining several separate images. The images are tiled on the composite image optionally adorned with a border, frame, image name, and more.

One of the innovative new features in the PowerBuilder 12.5.1 release is its ability to deploy PowerBuilder .NET code to run in 64-bit mode on 64-bit Windows platforms. In this article, after gaining background and perspective on 32- and 64-bit memory management and .NET deployment models, you'll explore the internals, strengths and limitations of this new feature.

Introduction
Almost all current server, desktop and notebook hardware platforms have 64-bit processors. Almost all current versions of Windows operating systems support both 32- and 64-bit platforms. With the 12.5.1 release, some PowerBuilder application software will be able to take full advantage of all available system memory. Read on to see if your code is a candidate for instant memory expansion.

Background
32-bit OS' can access a theoretical maximum 4 GB of RAM. In practice however, 32-bit Windows employs a 4-GB tuning model in which an application gets only 2 GB of virtual memory while the remaining 2 GB are assigned to the OS kernel. So the realistic maximum application memory is limited to 2GB. This limitation can only be released if the application was compiled with the /LARGEADDRESSAWARE option and the /3GB switch is set. In this situation, the application can get up to 3 GB of memory. (See PowerBuilder documentation on how to make the compiler large memory aware if you run out of memory when compiling your application.) PowerBuilder applications, not being large address aware, are therefore limited to 2GB RAM.

If you're familiar with the Database Binary / Text Large Object column type in PowerBuilder Classic (see Figure 1), you know it's a way of storing blob data associated with an OLE Automation application (Paint, Microsoft Word, Microsoft Excel) and then displaying it as part of a DataWindow.

There were some limitations with the Database Binary / Text Large Object. It required the end user to have the application that was used to add the object to the database in order to view the data. It often didn't display the data well within the DataWindow. And it wrapped the data stored in the database with an OLE wrapper, making it difficult to deal with the data outside of the OLE Automation application used to store it.

The migration march to PB 12.NET will have many shops revisiting legacy applications. In my previous article, "Refactoring Is Not an ‘R' Word" (PBDJ, Vol. 16, issue 12), you read why refactoring code before migration helps ensure smooth migration and enterprise integration. You were introduced to Test Driven Development methodology and saw how you can use it to ensure successful refactoring. You were also introduced to pbUnit, an open source tool and framework that you can use for both refactoring and developing new code in PB Classic applications. In this article I'll guide you through installing pbUnit and help you master the basic algorithm when refactoring your PB legacy code with pbUnit and test driven methodology.

Installing pbUnit and Configuring Your App: The Nuts and Bolts
In addition to installing and using pbUnit with Classic PowerBuilder to run unit Tests, you'll also learn how to get your code under test so you can go about refactoring your code with confidence. After that, I'll show you how to do a couple of refactorings to thin out a GUI and partition business and data logic

Now is the time to take that old code and whip it into shape. You suspect that unit test drive development has some merit and would like to try it out. This article will show you how to get started.

There are a couple of ways you can get your hands on pbUnit. You can download a PB v10.2 version from the Sybase CodeXchange. This version will migrate without error to version 10.5, 11.x or 12.0 Classic. Point your browser to http://www.sybase.com/developer/codexchange, then proceed to the PowerBuilder section and find pbUnit. You'll want to take version 3.2. Alternatively, if you want me know that you're trying out TDD, you can drop me an email and I'll send you a zip with a PB 12.0 compatible version. I didn't change the doc since I didn't make any changes to the code. I upped the version number on my zip to 3.3 to indicate the change.

This article seems like it should be the fourth in a series of articles. The first two were on non-visual components in August 2006 and July of 2007. The last one was in August of 2007. In that one, we looked at using the Interop Forms Toolkit to provide a COM wrapper for Visual .NET components - essentially making them ActiveX controls - so that PowerBuilder could use them. That article focused primarily on getting the visual component to display within PowerBuilder and being able to invoke functions on it. What we didn't look at then was allowing PowerBuilder to respond to events on the visual component. That's what we'll look at in this article.