Problem:        How To use Global Functions & Subs to replace extension functions not available on the current target platforms

Solution:        You can have an application that uses an extension to perform a function on one platform, but uses a global function or subroutine to perform the same function on another platform where that same extension might not be available.  You can use this method to prevent the compiler from complaining that the function does not exist on the current target platform.

This is easily handled with Global Subs and Functions, specifically the Private (not Shared) global funcs and subs.  Simply create a function or subroutine matching the name and parameters of the extension function which you do not have access to under that platform.  The sub does not have to do anything, though functions need to return a value.

This is very useful when porting apps between platforms.  For example, here is a global sub to handle the LockScreen and UnlockScreen

functions of the PalmDataPro SFScreenLock extension that is currently only available for PalmOS.  Place this code in your PocketPC target global functions and subroutines (Private) script section:

'global pseudo subroutines to replace extension calls

Sub LockScreen

'do nothing on PocketPC

End Sub

Sub UnlockScreen

'do nothing on PocketPC

End Sub

Now your existing PalmOS target code that uses the LockScreen/UnlockScreen functions can be compiled for PocketPC without compiler errors.

You can also use this technique to work out differences between PalmOS and PocketPC implementations of similar extensions, like the PalmOS Internet extension and the PocketPC Winsock extension.  While they share several common functions and design, they each have different platform-specific network setup and teardown functions.  As shown in the SatForms 6.1 cross platform SMTP and TCPIP Socket sample applications, we can use global functions to write common network code that runs on either platform.

In the older PalmOS-only SMTP sample, this code was used to initialize the network using the OpenNetLib extension function:

' open the network connection

Rec_data = "connecting..."

if ( OpenNetLib() <> 0 ) then

MsgBox("Error opening NetLib - " & GetLastError())

endif

In the new cross platform SMTP sample included with SatForms 6.1, this form level script is changed to this:

' open the network connection

'calls a private (per target) global script OpenNetwork to open network taking into

'account the different startup functions for PalmOS and PocketPC targets

Rec_data = "connecting..."

if ( OpenNetWork() <> 0 ) then

MsgBox("Error opening network - " & GetLastError())

endif

The above code is the same for the PalmOS and PocketPC targets.

Then, in the Global Funcs & Subs (Private) script for PalmOS, we have this

code:

'script function to open the network

'in the PalmOS implementation this calls OpenNetLib() extension function

Function OpenNetwork()

OpenNetwork = OpenNetLib()

End Function

'in the PalmOS implementation this calls CloseNetLib() extension function

Function CloseNetwork( closemode )

CloseNetwork = CloseNetLib(closemode)

End Function

In the Global Funcs & Subs (Private) script for the PocketPC target, we have

this code:

'script function to open the network

'in the PocketPC implementation this calls WSAStartup() extension function

Function OpenNetwork()

OpenNetwork = WSAStartup()

End Function

'in the PocketPC implementation this calls WSACleanup() extension procedure

'the close mode is ignored

Function CloseNetwork( closemode )

WSACleanup()

CloseNetwork = 0 'always return 0 on PPC

End Function

That's it -- all of the rest of the SMTP sample network code is the same for both the PalmOS and PPC targets, using the Internet and Winsock extensions.

Keywords:      extension, target, platform, compiler, global, function, sub

KB ID: 10016 

Updated: 2006-10-02

Satellite Forms KnowledgeBase Online

Satellite Forms Website Home