User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

In a previous blog article we looked at the new feature of PowerBuilder 2017 R2 for Subversion source control support. In this blog article we're going to look at a very similar feature, Git source control support.  I'm not going to go through the history of source code support in PowerBuilder again, I'd refer you to that previous blog article for that.  We're going dive straight in to how the Git feature works.

Setting up Git

For this demo, we're going to use Bonobo Git Server.  One reason I like it is because it provide a web based admin console for managing the server, so I don't have to use the Git command line to do that.

Because it's an ASP.Net application, the machine where we're going to install it must have IIS and the .Net Framework 4.6 installed on it.  To install Bonobo Git once you've downloaded it you simply need to:

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

Con los nuevos sistemas una de las cosas que hoy en día escuchamos es: tenemos un web services donde puedes consultar…

Por lo que ante esta necesidad y teniendo un sistema desarrollado originalmente en powerbuilder 6.5 ( les traigo esta solución.

Un “consumer” de WS REST

Para hacer este ejemplo utilizaremos objetos no visuales, principalmente el objeto internetresult.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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, 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.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

Microsoft recently released the Interop Forms Toolkit 2.0 in order to allow "developers to incorporate VB.NET Forms and Controls into their VB6 applications" ( FamilyID=934de3c5-dc85-4065-9327-96801e57b81d&DisplayLang=en).

The interesting thing is that it operates by automatically generating a COM Callable Wrapper (CCW) for the VB.NET forms and controls. That means that the .NET visual user controls are not only available to VB6, but to any Win32 application that supports COM, including PowerBuilder.

To test it out, I wrote a simple gradient user object in VB.NET (see Listing 1) and deployed it as an interop user control. I then added it to a PowerBuilder 10.5 window as an ActiveX (see Figure 1).

Everything on the window, with the exception of the gradient control, is standard PowerBuilder stuff. After some simple calculations to determine the combined RGB value the user has selected through the sliders and display it, it is applied to the gradient control through the following (of_calcstart and of_calcend are the routines used to calculate the RGB values):

long ll_start, ll_end
ll_start = of_calcstart()
ll_end = of_calcend()

//This will actually cause two repaints, but I don't care
ole_1.object.StartColor = ll_start
ole_1.object.EndColor = ll_end

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

It's been the bane of PowerBuilder development since day one. You have a DataWindow that contains one or more text blocks that, when previewed for printing or printed, span a page boundary. The result: the DataWindow incorrectly handles portions of the text. You may find some text on the first page that is repeated on the next page, or some text may be missing entirely, or the text may end up overwriting subsequent report objects. The bottom line is that the results are unusable, and it often takes a great deal of tweaking to get adequate results. The good news is that I found at least one method of addressing the issue. The bad news is that the path to get there was rather convoluted. This article describes both.

Beginning with PowerBuilder 9, the DataWindow has had the capability of exporting into XSLFO (XSL formatting objects) format. XSLFO is a variation of XML that contains formatting information in addition to the data. It is intended for use by a FOP (formatting objects processor) to render into any number of final output formats (e.g., PDF, RTF, HTML, etc.). In some sense it's similar to HTML, in that it contains formatting information and also because the syntax is somewhat similar. If you want to learn more about the actual structure and syntax of XSLFO documents, I recommend the tutorial on the w3schools site: Referring to that may be helpful when I start discussing some of the current limitations of PowerBuilder's XSLFO implementation. There is another good tutorial at the RenderX site: If you want to work directly with XSLFO documents and render them to PDF manually to see the result, I'd recommend the editX editor:

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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.

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.

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.