PowerBuilder 2017 R2 added a number of REST features, which I covered in a previous blog post.  One area for improvement on the original feature was better support for REST authentication methods.  The HTTPClient and RESTClient objects provided methods to set request headers, but doing the legwork needed for some of the more complex authentication mechanism (i.e., OAuth) were left to the developer.  PowerBuilder 2017 R3 addresses that.  In this blog post we'll look at using this new feature.

There were some JSON features introduced in 2017 R2, in particular the JSONGenerator and JSONParser, which were covered in a previous blog post.  2017 R3 introduces additional important JSON features, in particular JSON import/export from a DataWindow, and a JSONPackage object that is used to merge/extract JSON data sets.  Those will be covered in this blog post.

Support for using Git as a source control system without going through a bridge product was added in 2017 R2 and covered in a previous blog post.  In this blog post we're going to look at the enhancements that were added to that feature in 2017 R3. 

In SQL Server it is generally a good idea to use temporary tables, rather than table variables within your stored procedures. Temporary tables perform much better, particularly with large volumes of data, as SQL Server is able to compile statistics on the data in temporary tables. However, if you are calling your stored procedures from a Powerbuilder application,  you may find that the switch to temporary tables has an unwanted side effect. Here is how the unwanted side effect comes around and what to do about it. 

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.

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)