Up through Windows XP, if you wanted to get the physical location of certain defined folders (e.g. the users Documents folder), you would use the SHGetFolderPath function in the Windows API.  Roland Smith has examples of using that on his Topwiz Software site.  That function continues to work in later versions of Windows, although it's basically a wrapper for the SHGetKnownFolderPath function.

SHGetFolderPath uses CSIDL values, whereas SHGetKnownFolderPath uses KnownFolderID GUIDs.  One difference is that there are a lot more KnownFolderIDs than there are CSIDLs.  That means some of the defined folder locations you may want to get the physical location for can't be accessed through the older SHGetFolderPath method.  And that's exactly the situation I ran into.

I needed to find the user's Downloads folder, and there isn't a CSIDL value for that.  So, I needed to see how to call the SHGetKnownFolderPath function from PowerBuilder.  As with many OLE and Windows API calls, it can save you a lot of time if you can find some Visual Basic code that does what you need to do, and you can convert the syntax.  And fortunately, I found some that did this.

This article describes how you can emulate C# style enumeration types in PowerScript since PowerScript currently does not support creation of custom enumerations. Personally, I found myself in need of such enumerations when interfacing to Microsoft Word/Excel using OLE Automation.

Calls to Word or Excel functions without enumerated values (or named constants) are incredibly hard to read and understand. An example:

oleDocument.Selection.Move( 10, 2)
oleDocument.Selection.Move( 12, 4)

Using C# style enumerations, the same code could read like this:

oleDocument.Selection.Move( wdUnits.Row, 2)
oleDocument.Selection.Move( wdUnits.Cell, 4)

• Insertar un breakpoint.- Ejecute la opción de menú principal: Edit/ Insert BreakPoint
  • Requisito: Debes estar en el editor de código (script) .
• Inicializar el depurador. Ejecute la opción de menú principal: Run / Debug nombre de su aplicación
  • Ejecute la opción Debug  / Start nombre de su aplicación
• Ejecutar línea por línea.- F8
• Detener el depurador.-  Debug/Stop
• Ver el contenido de una variable.—Seleccione la variable, dar click derecho y escoger la opción quickwatch
  • Requisito: Debe estar ejecutándose la aplicación en modo de depuración

Truco: Algunas veces tenemos un error en tiempo de ejecución que nos hace que Powerbuilder se cierre, para localizar en donde ocurre esto la opción Depurar en tiempo de ejecución ayuda mucho.

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:

PowerBuilder's initial support for version control systems required drivers for specific vendors (e.g., PVCS) and often for specific versions of that vendor's products.  It was not unusual to find that you needed to wait to upgrade your source control product until PowerBuilder released an updated driver for it.  And if your source control provider wasn't supported by PowerBuilder you were simply out of luck.

That changed with PowerBuilder 6.  With that release, PowerBuilder abandoned the vendor specific drivers in favor of the recently introduced Microsoft Source Code Control Interface (MSSCCI).  Essentially an ODBC for version control, it freed the IDE from vendor lock-in.  Provide the source control provide provides an MSSCCI complaint interface, or there was a 'bridge' product available that could convert MSSCCI calls into the source control providers native API calls, PowerBuilder could use the product.

One of the new features added to PowerBuilder 2017 R2 is support for REST web services.  This feature isn't 100% complete, as additional REST functionality is planned for 2017 R3.  There's still a lot in the R2 release to look at though.

To make things simple for the demo, we're going to use a online REST web service called JSONPlaceHolder..  The service doesn't require creating an account or user authentication.  While the GET (retrieve) methods are fully functional the POST ( insert ), PUT/PATCH ( update ) and DELETE (delete) methods are placeholders.  They return result codes or in the case of POST the id value of the inserted row, but they don't actually modify the data.

Note that while REST web services can return data in any internet mime encodable format, the vast majority of them use JSON  and JSON is the only data format supported by the REST client object in PowerBuilder 2017.

The stand alone compiler was first introduced in PowerBuilder 2017.  It's primarily of interest for shops who perform routine (perhaps daily) builds of their PowerBuilder based applications, usually in order to perform manual and/or automated testing in order to capture bugs as soon as possible after they are introduced into the code base.

While you could perform command line compiles using the PowerBuilder IDE (and still can) it does require an additional license for the IDE, and it has a few drawbacks (e.g., stopping and displaying a messagebox nobody can see on some error rather than exiting with an error code).

One issue with the initial version of the command line compiler introduced in PowerBuilder 2017 is that it didn't support every option available in the PowerBuilder project painter.  Therefore, if there was some particular feature that use used in the project painter (e.g., generating an external manifest or no manifest at all) it wasn't possible to use the stand alone compiler and get the results you needed.