User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar 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:

User Rating: 3 / 5

Star ActiveStar ActiveStar ActiveStar InactiveStar Inactive

It will come as a surprise to no one that PowerBuilder's native graphing capabilities are somewhat lacking. Even the Define Graph Style dialog for the DataWindow graph style seems to have been left out of the GUI update in PowerBuilder 10.5 (see Figure 1). Forget Windows 95, this looks like something out of the version of Excel that came with Windows 3.1.

So what would we want from updated graphing capabilities? I can think of a few important features:

  1. Something that would work equally well in a Web application as a client/server one.
  2. Transitions, to allow some animation in the graphic during its initial display.
  3. Click-through, making it possible to respond to actions on the chart to drill down into additional information, whether it be additional charts or just access to the underlying data.
  4. More control over the generation of the chart. For example, for 3D pie charts we should be able to explode segments and have control over the amount each segment is exploded.
  5. An updated look-and-feel. That's a little hard to put into words, but what we want to do is make Figure 2 look like Figure 3.

User Rating: 2 / 5

Star ActiveStar ActiveStar InactiveStar InactiveStar Inactive

I'm doing some work on an application to aid in the mass update of various datawindow attributes. It's not rocket science since you are dealing with a series of text files and doing some basic 'find and replace' operations. However, if you have ever worked on a project which has been around for a while you will notice that datawindows do not get 'migrated' when you upgrade to a newer version of PowerBuilder; the export syntax remains at the version in which the thing was last modified and saved.

Now you might think that using the LibraryExport and LibraryImport methods will do the trick but you would be mistaken. A newly imported datawindow object keeps the same version as when it was exported.

To accomplish the task you need to use the datawindow CREATE method.