Monday, October 16, 2017

PowerBuilder User Group Meeting Germany

November 13th and 14th at the Mercure Hotel MOA Berlin https://www.linkedin.com/groups/103059/103059-6323593838392938498

PowerBuilder User Group Meeting Switzerland

November 15, 2017 at the Novotel Zurich City Hotel in Zurich https://www.appeon.com/company/events/powerbuilder-user-group-meeting-switzerland.html

Tuesday, August 08, 2017

Spell checking in the new PowerBuilder 2017 Rich Text Edit Control

The original Rich Text Editing control shipped with PowerBuilder was based on an OEM of a popular third party control at the time called HighEdit. By the time 10.5 came out though, that control was quite dated and no longer supported by the vendor. As a result, in 2006 Sybase replaced that control with an OEM of another popular third party control called TX Text Control. There are licensing issues with that control though.  So with the release of PowerBuilder 2017 Appeon updated the control again, replacing the OEM of the TX Text Control with an OEM of the TE Edit Control. Note that if you encounter regressions with the new control you can switch back to the TX Text Control through a new RichTextEdit option in the Additional Properties dialog for the application object.  If you do however, you will have to obtain your own license of TX Text Control.


One feature that became possible when Sybase adopted the OEM of the TX Text Control was in place spell checking of the text through third party utilities like JRSpell, WSpell or VSSpell. With the previous control, about the only thing you could do was copy out the unformatted text, spell check that using Word through OLE Automation, and then paste back in corrected, but unformatted, text.  Many people found losing the formatting of the text an unpleasant side effect of spell checking that way.  The new controlled allowed spell checking to be done without losing formatting.


In order for those third party utilities to perform in place spell checking, they needed to be provided with the handle to the control containing the rich text.  In an article I did for the PowerBuilder Developers Journal when the control was first introduced, I provide sample code for obtaining the control handle to pass to those utilities.  The sample code was essentially this, where a_rte is a reference to the PowerBuilder rich text edit control:

 ulong        hWin  
 hWin = Handle ( a_rte )  
 hWin = FindWindowEx ( hWin, 0, "PBTxTextControl", 0 )  
 hWin = FindWindowEx ( hWin, 0, "AfxOleControl42u", 0 )  
 hWin = FindWindowEx ( hWin, 0, "TX11P", 0 )  

Starting with the PowerBuilder RTE control we had to drill down three levels until we reached the part of the OEM TX Text Control that contained the text.  FindWindowEx is a windows API call to get a control handle based on a class name.  The text values included here are the class names that PowerBuilder used for the various controls.  Note that each time a new version of PowerBuilder was released and referenced a newer version of the TX Text Control the last class name used here had to be updated for the class name for that version.

With the new rich text edit control in PowerBuilder 2017 we use the same technique, though we don't have to drill down quite so deeply.  The code I'm using now in my migrated PowerBuilder 2017 application looks like this.

 ulong        hWin  
 hWin = Handle ( a_rte )  
 hWin = FindWindowEx ( hWin, 0, "Ter24Class", 0 )  


Saturday, July 15, 2017

The return of browser plugins?

Apparently there is a W3C open standard currently in development called WebAssembly that is "a memory-safe, sandboxed execution environment" for browsers (and non web use).  The binary formatted code in WebAssembly deployment can be parsed up to 20 times faster than JavaScript can be parsed.  While the working group has been focused on providing support for C/C++ a project called Blazor has been developed that provides support for C#.

InfoQ article


Thursday, July 13, 2017

Continuous Integration with PowerBuilder 2017, Bonobo Git and Jenkins

In a previous blog post I examined how we could use the Git MSSCCI provider from PB Software in order to use GitHub as a source code provider for PowerBuilder.

In this blog post we're going to take that to the next step, in that we're going to create a build machine separate from our PowerBuilder development machine and then set it up to perform continuous integration.  The term "continuous integration" has a somewhat ambiguous definition, but generally it means that:
  • developers check in changes frequently (at least daily) and
  • that build are done on a regular basis (at least daily, but can be as frequently as after each check-in)
Ideally, automated testing routines would be run on each build to ensure that feedback on any functionality that was broken by the latest code changes are returned to the developers as soon as possible.  Automated testing is outside the scope of this particular article

One of the new features added in PowerBuilder 2017 is a license free stand alone compiler and we're going to use that for this article.   If you are using a older version of PowerBuilder you could use the same approach using the command line argument feature of the PowerBuilder IDE, but it would require installing the full PowerBuilder IDE (including a license) on the build machine.  Alternatively, regardless of which version of PowerBuilder you're using you could use PowerGen in scripted mode.

Prerequisites

  • A windows machine (can be virtual) with .Net Framework 4.6 and IIS configured for ASP.Net
  • Bonobo Git Server
  • Jenkins
  • AutoCompile.exe from the C:\Program Files (x86)\Appeon\PowerBuilder 17.0\AutoCompiler directory from your PowerBuilder 2017 install

Install Bonobo Git Server

Bonobo is a ASP.Net application, hence the need for the machine we're installing it on to have the .Net Framework installed and IIS configured for ASP.Net.  Installation is fairly straightforward, as all you need to do is:

  • Copy the main folder from the unzipped download into the wwwroot folder for IIS
  • Give the IIS User modify and write permissions to the App_Data folder of the app
  • Convert the folder into an Application in IIS Manager
  • Ensure that the app pool that the application uses is based on .Net 4.0 rather than 2.0

Install Jenkins

The Jenkins install is also fairly straightforward as it uses a standard Windows installer.  After the install is complete it will generate a random password for the administrator into a file within the install and provide you with a message as to where to locate it.  You will need that password to do the initial login and configuration of Jenkins.

One you have started Jenkins it will prompt you as to the plugins you wish to install.  There are 1000+ plugins available for Jenkins.  The primary one we're interested in is the Git plugin, which is part of the default set of plugins that Jenkins will recommend for use. You can just accept their recommendations.

Install AutoCompile

Autocompile has a fairly simple install too, and automatically adds the install directory to the system path.

Configure Jenkins

Change the Jenkins URL from localhost to the actual name of the server that it's running on.


Create a Repository in Bononbo

You need to be logged in as the admin user to create a repository.  The only thing you have to provide is the name.


Once you're back at the list of repositories you can use the option there to copy the url for the new repository to the clipboard.


Configure the PowerBuilder IDE to use the new repository

Technically what you will be doing is configuring the PowerBuilder IDE to use a local repository and then configuring that local repository to use the new repository as a remote.  The detailed steps are outlined in my earlier article about using GitHub.  In summary, the steps are:


  1. Use TortoiseGit to create a new 'bare' repository in the directory where the PowerBuilder source is located.
  2. Create a small text file (e.g., readme.md) in the directory.
  3. Use TortoiseGit to add and commit the file.
  4. In PowerBuilder, select PGS Git MSSCCI as the source control system for the workspace.  Make sure that "Suppress prompts to overwrite read-only files" is checked.
  5. In PowerBuilder, add the application target(s) to source control.
  6. In PowerBuilder, add the remaining PowerBuilder objects to source control.
  7. In TortoiseGit settings for the directory, configure the Bonobo repository you created above as a remote repository for the local repository.
  8. In TortoiseGit, do a push from the local repository to the remote repository.

Create a new 'FreeStyle Project' in Jenkins



Under the Source Code Management section of the new project, select Git and then provide the repository URL and credentials to connect to the Git server.


Under the Build Triggers, specify any automatic build triggers you want to use.  For this example, I'm going to use "Poll SCM" and configure it to poll every 15 minutes.


Do a "Build Now" on the project


Because we haven't created any build steps yet this won't build anything yet.  What it will do is create a workspace under C:\Program Files (x86)\Jenkins\workspace and populate it with the current source code from the Git repository.

Create ORCAscript and batch files

Create an ORCAScript file to create PBLs from the source code (createpbls.orca):

 start session
 set debug true
 scc set connect property logfile "createpbls.log"
 scc connect offline  
 scc set target "pfc_ci\pfc_ci.pbt" importonly
 scc exclude liblist "pbdom\pbdom170.pbd"  
 scc refresh target 3pass
 scc close  
 end session  

Because Jenkins pulled the source code for us already we don't have to provide source control settings in the ORCAScript file and can use scc connect offline.  "ImportOnly" tells ORCAScript to build PBLs from source.  "Refresh Target 3pass" tells ORCAScript to do a multi-pass compile.  I'm using a sample app based on a recent version of the open source PFC, which now includes a reference to PBDOM.  Therefore I'm using "scc exclude liblist" to tell ORCAScript to ignore that library during the source code import.

Create a batch file that will run the ORCAScript executable on the ORCAScript file (run_orcascript.cmd).

 orcascr170 createpbls.orca  

Create a batch file to call the PowerBuilder stand alone compiler.  We're going to need to pass a number of arguments to the compiler.  Fortunately, the application project object in PowerBuilder shows you the arguments you would need to pass to match the settings in the project object.



Using those arguments - modified slightly because we're deploying in a different location - we should have something like this (run_pbc.cmd):

 pbc170 /d "pfc_ci\pfc_ci.pbt" /o "pfc_ci\pfc_ci.exe" /w n /m n /x 32 /p "PowerBuilder Enterprise Series" /cp "Appeon" /de "Appeon Product File" /v "1.0.0.1" /fv "1.0.0.1"   

Finally, create a batch file that will copy the generated exe and pbd files into another directory when the build is complete (copyfiles.cmd).

 md c:\builds\%JOB_NAME%_%BUILD_NUMBER%\  
 FOR /d %%a in (*) do copy %%a\*.exe c:\builds\%JOB_NAME%_%BUILD_NUMBER%\  
 FOR /d %%a in (*) do copy %%a\*.pbd c:\builds\%JOB_NAME%_%BUILD_NUMBER%\  

This batch files uses environment variables that Jenkins makes available when the batch file is run to create a separate directory for each build.

Create Build Steps

Go back into the Jenkins project and under Build add a Build Step that executes a batch command.


Specify the run_orcascript.cmd file as the first batch file to run.


Add another build step after the orcascript step and point this one at the run_pbc.cmd file.  Finally, create one more build step after the run_pbc one and have it run the copyfiles.cmd file.

Do a Build Now on the project

We're going to test out our scripts to make sure that Jenkins can do the build.  Once you've scheduled a build you should see it being processed in the list of builds.


If you click on the build, you'll be taken to another page with more details, including the ability to view the console output from the running build.


Test the SCM poll

Now that we know the build works, let's see if we actually have continuous integration.  Go back into PowerBuilder and check out an object.  Make a trivial change and commit it.  Then using TortoiseGit, push that change to the Bonoho repository.  Now watch Jenkins and what you should see is that some time after Bonoho has been updated (depending on what you set the SCM polling time to in Jenkins) Jenkins will automatically launch a build of the project.

Next Steps

That gives us the basics of a continuous integration setup.  I'm going to be looking at taking it a bit further.  In particular.

  • There is a Jenkins plugin for the Visual Studio command line build utility (MSBUILD).  I'm looking a creating a similar plugin for the PowerBuilder build utility.
  • Integration with JIRA.  Rather than firing a build on every checkin, the checkins would be tagged with a JIRA issue and the build would only fire when the JIRA issue is moved to the JIRA "Waiting for Deployment" status.





Monday, July 10, 2017

PowerGen 9.5 for PowerBuilder released

In addition to support for PowerBuilder 2017, the new version offers support for EAS builds, better handling of extended characters in object names and other new features and bug fixes.  For more information, see the release notes.

Tuesday, May 23, 2017

Configuring PowerBuilder projects to use GitHub for source control

Back in 2003, Sybase introduced CodeXchange, an online forum that allowed developers to share code samples and collaborate on open source projects.  Unfortunately, in 2009 Sybase decided to shut down that system.  The PowerBuilder code samples that had been uploaded tp CodeExchange did eventually show up again in a CodeXchange section of the PowerBuilder wiki on SAP's SCN.  Appeon also obtained permission from many of the authors to post those same PowerBuilder samples on the Code Samples section of the Appeon site.

However, the people who had collaborator projects on CodeXchange needed another option, because neither the SAP PowerBuilder wiki or the Appeon Code Samples site allowed for collaborative development.  Aware of the pending shutdown, I moved the PFC and PBNISMTP projects to Microsoft's CodePlex.

Like CodeXchange, code in CodePlex could be access from PowerBuilder through a MSSCCI to SVN proxy product.  That's because PowerBuilder uses an MSSCCI API to talk to source control systems, but both of those systems used an SVN API.  A bridge product like PushOK SVN SCC translates the MSSCCI calls to SVN calls so that the client and the source code repository can communicate.

Unfortunately, Microsoft has announced that it intends to shutdown CodePlex on December 15th, 2017,  That means those of use that moved our projects to CodePlex need to once again move them someplace else.  One potential new location is SourceForge, which also supports an SVN API.  In fact, Roy Kiesler put the PowerPrinter source code there back in 2001.

However, the site that Microsoft recommends as a replacement, and the one that has become the dominant open source hosting facility, is GitHub. The issue with moving to GitHub is that it uses a Git API rather than an SVN API, which means we need to find another proxy product to translate the MSSCCI calls to Git.

If we've been using the PushOK SVN SCC product to date to handle SVN, the first thing we might want to check out is their Git SCC product.  Unfortunately all we would find when we attempt to download the product though is a 1.0 release candidate that was published in June of 2010 and hasn't been updated since.  That's hardly reassuring.  We might also note if we went back to their SVN SCC product that the last update of that was also a release candidate for supporting SVN 1.8 published in April of 2015 and not updated since.  Subversion 1.9 was released in 2015 and the current version is 1.9.5.  It appears that PushOK has ceased development of their products sometime in the last two years.

Fortunately, there is an alternative.  A bit of searching turned up a the Git MSSCCI provider from PB Software.  It not only works, but it's free.  It's also being actively supported.  There have been releases in 2014, 2015 and 2017.

I'm going to walk through how to configure PowerBuilder to use the PB Software provider to connect PowerBuilder to GitHub.  Perhaps because of my somewhat limited experience with Git (I've used the GitHub desktop to host a JavaScript project there and the GitHub extension for Visual Studio to host a C++ project there.  Those were pretty idiot proof.  Configuring PowerBuilder to use the Git MSSCCI provider takes a bit more work.  A owe a lot of thanks to Bob Piskac of PB Software for walking me through some of the issues.

1.  Download the zip file with the provider and unzip it to your file system somewhere.  I chose to put it under the C:\Program Files(x86) directory, specifically at C:\Program Files (x86)\pbsGitMSSCCIV1build0007.

2.  Add that directory to your system path.

3.  The provider does not automatically create the registry entries needed for PowerBuilder to find it as a source control provider, despite what the readme document that comes with the download indicates.  Instead, add the following to your registry (modified as needed to match the location where you installed the provider in step 1.).  These entries are for a 64 bit machine.  If you're on a 32 bit machine still, simply remove the Wow6432Node portion of the keys.

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SourceCodeControlProvider]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SourceCodeControlProvider\InstalledSCCProviders]
"PB Native"="Software\\Sybase\\PowerBuilder\\12.6\\Native SCC"
"PBS Git MSSCCI"="Software\\PBSoftware\\PBSGitMSSCCI"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PBSoftware]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PBSoftware\PBSGitMSSCCI]
"SCCServerName"="PBS Git MSSCCI"
"SCCServerPath"="C:\\Program Files (x86)\\pbsGitMSSCCIV1build0007\\pbsGitMSSCCI.dll"

Bob did indicate that he was looking and creating another build that would produce those entries automatically when regsvr32 is run on the DLL.

The Git MSSCCI provider expects the PowerBuilder project to already be in a local Git repository, so we're going to create that now.

4.  Download and install TortoiseGit.  Not absolutely necessary, but I like to with with a GUI rather than the command line and TortoiseGit serves as the GUI for some of the initial work we need to do with Git.

5.  Create a GitHub account if you don't already have one.

6.  Create a new repository in Github for your project.  Leave it empty right now.

a.  Select create project from the main page.

b.  Give it a name and hit Create Repository.  Leave the checkbox to create a readme file unchecked.

c.  You should end up with a page that looks like the following.  Keep it open, as we will need the url for the project in a later step.

7.  Find the parent directory of the PowerBuilder code that you want to start hosting in GitHub, Right click on that directory and select the "Git create repository here" option.

Leave the  "Make it Bare" option unchecked and hit OK.

8.  Open the directory, right click in it and create a new text document.  Name the new text document README.md (with README in capitals).


9.  Right click on the README.md file and select Add from the TortoiseGit menu option.





10.  Right click on the file again and select "Git Commit -> "master" to commit the add to the local repository.





11.  Right click in the background of the directory and select TortoiseGit Settings.


Click OK on the dialog that appears that explains hierarchical configuration.

12.  In the settings, find Git - Remote.  Enter the URL from the project in GitHub into the URL field and hit Apply.


Click "No" when asked if you want to fetch remote branches.

Press OK on the next dialog and you should see this result.


13.  Right click in the directory background again, and this time select TortoiseGit -> Push.


That takes the files that have been committed locally and updates the remote repository with them. You will be prompted for your GitHub username and password.  You should see a summary dialog like this when you are done.


14.  The repository is now ready for you to start working with it from PowerBuilder.  Open up the IDE and the workspace in question.

15.  Open the workspace properties and select PBS Git MSSCCI from the list of source control systems.


Make sure you check the "Suppress prompts to overwrite read-only files" option and hit Apply.


16.  The output pane should indicate that the connection to source control was established.  You can now right click on the workspace and select Add to Source Control.


17.  Go back to the directory where the source code is at, right click in the directory and select TortoiseGit -> Push to send the PowerBuilder code to GitHub.  Alternatively, you can use GitHub Desktop and the Publish option as shown below.


Initially you'll need to Add the local repository to GitHub Desktop so it knows to work with it.

18.  Go back to your project in GitHub, refresh the page if necessary, and see all your code.


One thing to keep in mind is that Git is a distributed version control system.  PowerBuilder talks to your local git repository, so you can work offline.  You have to go online and do a sync with GitHub in order to post your changes and pick up changes from other users.  You'll need to use TortoiseGit, GitHub Desktop, or even the git command line to do that.

On a final note, I'm not the first person to post PowerBuilder projects to GitHub, there are already a number of existing projects there.


Thursday, April 20, 2017