User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

One of the reasons that people choose to use Git is how easy it is to do branching. Unfortunately, PowerBuilder hasn't implemented it yet. But that doesn't stop you from using this feature if you don't mind taking a few extra steps. This article shows you how you can work on different branches with the help of TortoiseGit. 

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Many PowerBuilder developers want to try Git as it gains in popularity. However, as PowerBuilder IDE still relies on the binary PBL format instead of directly working with the plain text source code files, the implementation of native Git support comes with some special features that you may need to be aware of in order to use Git properly or to work around some of the limitations. This article tries to give some tips in this area.

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

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)

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

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.

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

I have a function called "GuardarAExcel2()" which uses a step datawindow called "d_filafichero". With this function you generate an excel with the same visual aspect as your datawindow. I hope it helps you:

Example of use:

GuardarAExcel2( dw_1, "c:\Report.xls")
GuardarAExcel2( dw_1, "c:\Report.html")

Result in datawindow:

 

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

Perhaps you’ve enabled the titlebar and control menu of a DataWindow control.  You may even want the users to be able to minimize/maximize and reposition the control at runtime.

DataWindow Control Properties

Now you’d like to trap when the user interacts with the control in this fashion in order to execute some logic when they do. Perhaps you’d like to know when/if the user closes the DataWindow control.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

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.

User Rating: 4 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Inactive

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.

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

Back in August of 2006, I wrote an article about calling .NET components from PowerBuilder using COM wrappers (i.e., CCW). Since I was basing it on a registry entry approach, the technique demonstrated required the component to be added to the GAC, which in turn required that we create a strong name and sign the assembly (besides having it compiled as a COM-visible assembly).

You don't always have access to the GAC or the registry of the machine that you need to deploy your application to. Well, fortunately we have some options. Beginning with Windows XP and Windows Server 2003, the Microsoft operating systems allowed the use of manifest files rather than registry entries for loading COM components. It not only works for regular COM components, but for .NET components that have been exposed as COM-visible. The only difference is how the manifest file is structured.

If you want further information on the details, I'd recommend the following resources: