I plan to make this the first of a series of articles that discuss the new features in PowerBuilder 11.5, which was released late last year. Of course, they won't be the first articles we've run on the topic, as we ran an article on the new Code Access Security features back even before 11.5 was released and a more recent article on New DataWindow Features. This series of articles is intended to discuss the major hitters of the remaining features.

FDCC Compliance
At the risk of putting my readers to sleep I'll cover the FDCC compliance first. Not because most PowerBuilder developers need or want this functionality, but because most PowerBuilder developers using PowerBuilder 11.5 are going to be affected by it nonetheless. What FDCC compliance gets at, viewed from a bigger perspective, is the issue of being able to run applications in an environment where the user has restricted user rights. It's something I deal with regularly with the applications I end up writing, because many of them are used in environments where the end user has limited rights on the workstation.

For example, in many cases the user does not have permission to write entries into most or all of the registry, and generally they will have file write capability only within their own Documents and Settings section of the local hard drive. When one of my applications is installed, it's generally done through rights elevation, either through an SMS push or by an administrator logging onto the machine to perform the install.

Some Background
There are four principal locations of the user's Documents and Settings folder structure that are of particular interest when developing applications for limited end-user rights scenarios (the name is dependent on the operating system involved):

1. My Documents (or Documents): Somewhat obvious, the area where your app will save files that the user can access after the application finishes running (Excel Exports, Save As PDF, etc.).
2. Application Data (or AppData): A system folder - normally hidden from the user - in which you can store small application-specific files (e.g., your application INI file). There should be a subfolder specific to your application that you store your files in. You should also be aware that there may be a limit imposed on the entire size of the Application Data section by the operating system. This is because Application Data is one of the folders that is involved in roaming profiles, so the size is often restricted to prevent the need to move large amounts of data in those profiles.
3. Local Settings\Application Data (or AppData\Local): Another system folder, also normally hidden from the user and one in which you should have an application-specific subfolder to store your applications' files. Because this folder is not involved in roaming profiles, there is usually not a restriction on its size, and your application can store much larger files. We allow users to download the application's help file to their local machine so we can do live updates. As a result, we download it into their Local Settings/Application Data folder and then open it from there. In addition, we store a number of other application-specific files there, such as image files we can't embed into the application and our EBF PBD, so that we can add minor mods to the application without requiring a re-install of the application. The one downside is that since this folder is not part of roaming profiles, all of the files downloaded to this area are specific to that user on that machine. If you do use roaming profiles, your users would have to re-download the files on each machine they use.
4. Local Settings\Temp ( or AppData\Temp): You cannot assume that the location pointed to by the TEMP and TMP environmental variables always point to a location that the user has write privileges to (although in most cases they will point to this folder). To be safe, you should refer directly to this folder, preferably to a subfolder (although you don't need to give it an application-specific name, since it will be purged at some point). This is the work area you would use to store temporary files only used as intermediates during application processing.

All this time I've been discussing the folders that appear under the individual users Documents and Settings folders. For example:

C:\Documents and Settings\<username>\My Documents
C:\Documents and Settings\<username>\Application Data
C:\Documents and Settings\<username>\Local Settings\Application Data
C:\Documents and Settings\<username>\Local Settings\Temp

However, there are also a couple of similar folders under the "All Users" user:

C:\Documents and Settings\All Users\Shared Documents
C:\Documents and Settings\All Users\Application Data

You would use those locations where you wanted to allow all of the users to access a single copy of a particular file, rather than each user having his or her own copy.

When you are writing your own applications and want to ensure that they will work properly in a limited end-user rights environment, the SHGetFolderPath Windows API function will quickly become your friend. Simply send in an enumerated value (called a CSIDL) and it will return the location for that particular folder. It actually handles many more special folders than we care about here; the CSIDL values that we are primarily interested in are shown in Table 1.

The exception, as noted in Table 1, is the Local Settings/Temp folder. There isn't a specific CSLID for it, although there is one for somewhat related folders (e.g., CSIDL_INTERNET_CACHE, which points to Local Settings/Temporary Internet Files). There is a GetTempPath function in the Windows API, but what that returns is the settings for the TEMP or TMP environmental variable. We've seen situations in which someone with admin rights on a workstation has set that variable to point to a location (e.g., C:\TEMP, C:\WINDOWS\TEMP) that a rights-restricted user would not be able to access logging into the same machine. As a result, it may be safer to query for a value such as CSIDL_INTERNET_CACHE and then adjust the value to get to the Temp folder.

Also of note, the MSDN documentation indicates that the SHGetFolderPath function has been deprecated. While that is the case, the new version of the function only works on a rather limited subset of Windows operating systems. For compatibility with older operating systems, you may want to consider sticking with the SHGetFolderPath until such time as Microsoft actually removes it from some future version of the operating system.

How that Affects PowerBuilder
Everything we've talked about so far has to do with applications that you write for users with limited rights. However, in some shops even software developers who use the PowerBuilder IDE are required to run with limited end-user rights. Therefore, it was important to ensure that the PowerBuilder IDE also ran properly in such environments. What this means principally is that stuff you would be able to write to that you used to find in the Program Files/Sybase folder structure has been moved to other locations. Those files generally fall into two categories: those that all users share, and those that are specific to individual users, as shown in Table 2.

While the most effect this will have on a majority of developers is to cause confusion (because they won't find files where they are most used to seeing them), it also serves as an example as to how you might modify your own applications for limited user rights. Particularly as new operating systems arrive (Vista, Windows 7) and limited user rights become more prevalent, it's something you'll probably have to deal with eventually.