Wednesday, January 29, 2014

Insufficient Storage Available errors on Android

Mostly just a note to self.  Apparently since the 4.2 update, you can get "Insufficient Storage Available" errors when updating apps on Android when there is plenty of free space available.  The solution is to enter "*#9900#" on the phone keypad and then select "Delete dumpstate/logcat".  For further info, see this thread:

http://stackoverflow.com/questions/16818049/insufficient-storage-available-even-there-is-lot-of-free-space-in-device-memor

Tuesday, January 21, 2014

FAQ: How can I send SMTP from PowerBuilder

PowerBuilder's only native method of sending email is through Simple MAPI, which is very limited.  In particular, the approach was hampered quite a bit when Microsoft introduced security enhancements which resulted in security warnings being generated anytime Simple MAPI was used.

The most popular approach for addressing this has been to use SMTP to send email instead.  There are quite a number of third party tools that can be used to accomplish this:

  • Topwiz Software's EmailSMTP is a PowerBuilder non-visual user object that uses Windows API calls to send SMTP.


  • This blog post explains how to create a .Net assembly that can then be wrapped via a COM Callable Wrapper and called from Classic PowerBuilder.  The blog article uses Visual Studio and C# to create the assembly, but the assembly could also be created using PowerBuilder.Net.  The STMPClient.zip file in these PowerBuilder Samples on Google Drive is an example of doing just that.


  • Many databases have build in features for sending email such as SQL Anywhere's xp_startsmtp / xp_sendmail, Oracle's UTL_SMTP or UTL_MAIL, Microsoft SQL Server's Database Mail, etc.  Therefore, it is quite feasible to create a stored procedure in the database that handles email transmission and simply have the PowerBuilder client invoke that.

So, where do we go from here (e.g. WebForms)?

As you're probably already well aware, the .Net WebForms target was removed from PowerBuilder beginning with the 12.5.2 maintenance release.  The reason it was removed was because of a third party control that was implemented in the later versions of it (11.5.x, 12.x, and 12.5.x) which SAP is no longer authorized to distribute.  As a result, they had to pull it from the product as well as remove any EBFs or maintenance releases that contained it.
webforms.PNG
The question that came up quite a bit in the "Latest News from the PowerBuilder World" webinar, and which I've recieved by email since, is "what do we do now?".  This document is an attempt to address that.

Note that I've created it as a document rather than a blog post so that others can contribute as well.  If you know of a good alternative solution, feel free to add it.

Please don't feel compelled to criticize the suggestions made by others though.  Let's leave it to the end user to make their own evaluation of the pros and cons of the various approaches relative to their own environment.  Just because a solution works best for you doesn't mean it works best for everyone else.

1.  Stay with WebForms.  If you are already using WebForms, there is no need to stop using it.  As noted in the release notes for 12.5.2, subsequent EBFs are configured so that they can be applied to both the original 12.5.1 MR and the 12.5.2 MR.  If you want to continue to use webforms, simply don't apply the 12.5.2 MR.

2.  Appeon.  Appeon is a third party tool that takes PowerBuilder Classic (soon to be renamed to PowerBuilder Native) code and coverts it to a web application.  They recently also released a mobile version of their product that supports deployment to iOS as a native app with plans to expand the capability to Android and Windows Mobile in the near future.  Because the tool takes existing PowerBuilder code and converts it, you continue to do development using the PowerBuilder IDE, minimizing the amount of code rewrite necessary to support the web platform.

3.  Use RDP.  One of the presentations at last year's PowerBuilder Developer's Conference by Dimitri Joosten was entitled "VHG-Tools Platform PowerBuilder .NET, Expression Blend, Web and Cloud".  He later did a similar presentation on PowerBuilder.TV.  The approach was to move the application to PowerBuilder.NET in order to modernize it's appearance, and then use products like 2X to allow access to the application via the web and/or mobile devices.

4.  Rewrite to provide services to be called from HTML5.  Another of the presentations at least year's PowerBuilder Developer's Conference by Marcelle von Wendland was entitled "How to use PowerBuilder .NET to Architect Powerful Mobile Apps for Mobile Workers".  She also did a series of articles for the ISUG-TECH journal outlining the approach.  The approach was to migrate the application to PowerBuilder.NET and convert it to web services which are then accessed through a new HTML5 based front end.

5.  Create visual assmblies and then use those in a WPF Browser Application.  Unfortunately, PowerBuilder.NET's support for WPF doesn't extend to WPF Browser applications.  There are ways that it can be tweaked to support them, but the approach is risky.  However, with the release of 12.5, PowerBuilder.NET does support the generation of visual assemblies, and those can be used as the basis for a WPF Browser application written in Visual Studio.  I demonstrated a rather simple example in a recent blog post.

6. ASP.NET MVC Framework with PowerBuilder generated assemblies
Convert your business logic into assemblies using transactions and datastores (non visual only).
Use XML export templates to render data in HTML, map protect column property to the new contentEditable HTML5 attribute, different templates could address different devices. Use XML import templates and possibly XSL validation to import data into datastores.
Needs a lot of rewriting, good knowledge of .net and web techniques.

FAQ: What are my source control options for PowerBuilder

Source code control is used for one or more reasons:

     1.  To provide for a single common location with a master set of the source code being developed.
     2.  To provide checkin/checkout capability to ensure that two developers do not attempt to make incompatible code changes at the same time
     3.  To provide a history of source code changes.  This helps for instance by allowing changes that were done in error to be more easily reverted.

Prior to PowerBuilder 6, the source control options available from within PowerBuilder were limited.  This was primarily because a custom driver had to be created that enabled PowerBuilder to talk to the target source control system. Everything changed with PowerBuilder 6, when PowerBuilder implemented a standard API based upon the Microsoft Source Code Control Interface (MSSCCI).  In PowerBuilder 8, a PBNative option was added to provide an out-of-the-box source control option.  However, PBNative provides "minimal" source code versioning capability.

Note that no matter what source control option you use, you should - at least within PowerBuilder Classic - use the source control menu options provided within the PowerBuilder IDE.  That is because the PowerBuilder Classic IDE does not store individual source code files at the operating system level, but instead stores them in PowerBuilder libraries (PBLs).  Attempting to add the PBLs to a source control system has significant limitations, including restricting checkin/checkout capability to a PBL (preventing other developers from working with any objects in the library that you aren't working with) and dramatically limiting the ability to do version comparisons between edits.  The PowerBuilder.Net IDE does store individual source code files at the operating system level, and as a result your source code control options are much more open and beyond the scope of this article.

Source code options for PowerBuilder Classic fall in three general categories:

1.  Using PBNative:  This is the out of the box solution.  Note however that while it does provide for checkin/checkout capability to prevent more than one developer from editing the same source code at the same time, the approach provides little support for code versioning,

2.  Using a source control system that supports MSSCCI.  Once the client for such a system is installed on the workstation that PowerBuilder is installed on, the vendor should appear in the drop down within the PowerBuilder IDE for available source control systems.  There are a number of such systems available.  Two of interest because they are specifically designed for use with PowerBuilder are WizSource and PowerVSC.  Historically (even prior to PowerBuilder 7) vendors such as PVCS and ClearCase were very popular.  Other systems that support MSSCCI include Team Foundation ServerPlastic SCMSurround SCM, and SourceAnywhere,

3.  Use a non MSSCCI source control system for which there is a MSSCCI bridge product available.  A number of newer source control systems that do not support MSSCCI have become very popular lately.  Historically, CVS was a popular option, and more recently SVNGit and Mercurial have become very popular.  Such products can be used for source control from PowerBuilder provided there is an add-on utility that will convert the MSSCCI calls that the PowerBuilder IDE makes into the calls that the target source control system does understand.  Some available 'bridge' products include:



Git:    PushOK Git

Mercurial:  Currently the only know MSSCCI products for Mercurial are Visual Studio plugins that will not work with PowerBuilder.

FAQ: How do I learn more about using PowerBuilder?

  • The PowerBuilder Development Center,   Thediscussions blogs, and documents like this one are one way to learn more about using PowerBuilder.  There are a number of other options as well:
     
  • ELearnIT offers online video series with workshops.  More personalized training is also available through GoToMeeting or onsite training. 
  • PowerBuilder.TV offers a number of PowerBuilder related webinars monthly and has an archive of previous webinars. 
  • SAP has a Database and Tools Academy on Youtube with a number of videos on using PowerBuilder. 
  • For 20 years, the PowerBuilder Developer's Journal printed a monthly magazine with articles about PowerBuilder and related technologies.  The magazine ceased publication in early 2013, but archives of many of it's articles are available online. 
  • ISUG-TECH is the international SAP user group that focuses on technical users.  They offer a monthly magazine that includes PowerBuilder, a special interest group forum for PowerBuilder, a discount on ELearnIT training reference above as well as local user group meetings and conferences.