Sometimes it so happens that you have to provide the same facility in different forms and that requires the same code and at times it is very lengthy one. For example, I have Document Management by which one can look at the documents or insert new documents in the document subform (to be precise, it is link to the document).  Since I have to provide this facility to different people and as they work with different forms, they have to be at various places. Moreover, at times you are working with different forms and you want to have that facility right there.

This leads to having the same programming in different forms in the same application. These leads to unnecessary duplication. I am sure this will increase the time when loading as more to compile and when you have to change something in the coding, you have to do that at so many different locations. There has to be an easier way to avoid duplication and conserve the computer resources!!

Would you please show me a way?  Your feedback, guidance and help is always appreciated.

Thanks Steve. If it is the same form, no problem. Put the code in Global Code of the form and that is available to all the elements of the form.  This is really the question about the scope.  The term Application Programming suggests the scope is application wide. The subroutines or functions placed in application programming should be available anywhere in the application. But I do not think so as far as I know.

That leaves us precompilation constructs such as #define and #Include but I have know idea how can I place subroutines or functions in there. Just as you said, one of the Pro's can swoop in and set us straight.  

There is no way to have application-wide routines.  Application Programming only runs when the application is first started--the routines do not remain available.

On the other hand, each form has its own Global Code section, so when you switch forms you won't have access to code that is in another form just by using a procedure name.

FormRunCustomProgram can be used to run code in a different form, but that's usually poor programming practice.  Someone changing the code in the other form is not likely to check every other form for cross-form dependencies.  If the form that calls the other form's code is rarely used, it could be months or even years before the broken dependency is discovered, and at that point it might not be possible to determine what the former functionality was. Also, the form called must be open. And you can't use FormRunCustomProgram to run code in the current form.

Let's say you have a group of subroutines that reference fields in a particular form, e.g., [fields] FirstName, Surname, City.  If you put that code in a separate program file and #include it in the Global Code section of some other form that does not contain those fields, when you load that form the code won't compile.  With Sesame, either everything compiles or nothing compiles.

You can use one central external program file and #include it from various forms.  For subroutines that are specific to particular forms, in the Global Code of the calling form #define something, e.g.:


(Global Code section)
#define FORM_IS_EDUCATION_INFO "Education"

#include "Central_Program_Code_File.pgm"
if not FileExists("Central_Program_Code_File.pgm") @MsgBox("","Can't find Central Program Code Include file","")




Then in the central program file use:


#ifdef FORM_IS_EDUCATION_INFO

(SBasic specific to that particular form)

#endif

(whatever)


----------------------------------------------------------------

Several caveats:

If you have multiple procedures in the code file, remember that ALL variables outside a particular procedure declaration must be defined before ANY commands.  For purposes of compilation, the #include file is simply read in at that point. So, you can't perform a command and then #include a file that starts with variable definitions and then procedure definitions because from the compiler's perspective you are defining variables after code is run.



If you can, group all procedures specific to a specific form in a single #ifdef section.

In the procedure heading block it helps to mention which form calls that procedure, e.g.:


#ifdef FORMNAME_IS_STATUS
// FORM: Status
// ======================================================================
// SET SEARCH READABILITY [FORM-SPECIFIC]
// Set the writability of the Search tab LE's
// ======================================================================
Subroutine SetSearchReadability(vWritability as Int, vReadabilityPopup as Boolean)
     var vFieldStatus as String

     ReadOnly(Search_File_No, vWritability)
     ReadOnly(Search_Account_No, vWritability)
     ReadOnly(Search_Related_Files_Info, vWritability)

     
     If vReadabilityPopup
     {
     vFieldStatus = @Select(vWritability + 1, "Writable", "Read-only (grayed)", "Read-only (not grayed)")
     @MsgBox("","Search Tab Fields: " + vFieldStatus,"")
     }
End Subroutine // SetSearchReadability



// FORM: Status
// ======================================================================
// SET SEARCH TEXT COLOR [FORM-SPECIFIC]
// Set the text color of the Search tab LE's
// ======================================================================
Subroutine SetSearchTextColor(UpdateMode as Boolean)
     var fgRed      as Int = 0
     var fgGreen      as Int = 0
     var fgBlue      as Int = 0

End Subroutine // SetSearchTextColor

// (... Other procedures... )

// #ifdef FORMNAME_IS_STATUS
#endif


Note that #ifdef relies on the existence of the variable, not it's value.


Of course, your procedures can be set up that one parameter passed to them will trigger different sections of the procedure, e.g.

#ifdef ALL_PERSONAL_INFO_FORMS
Function BioInfo(FirstName as String, MiddleName as String, Surname as String, Birthdate as Date, BirthPlace as String, SourceForm as String) as String
  var Result as String = ""
  Result = FirstName
  if SourceForm = "Full Data" then Result = Result + " " + MiddleName
  Result = Result + " " + Surname
  if SourceForm = "Full Data" then (include the birth date and birth place)

  Return Result
End Function // BioInfo
// #ifdef ALL_PERSONAL_INFO_FORMS
#endif

For that function, if a "Short Data" form exists that doesn't contain MiddleName, BirthDate or BirthPlace fields, when calling the function you would have to pass it "filler" information, e.g:

(From Full Data form)

#define FORM_IS_FULL_DATA "Full Data"
#define ALL_PERSONAL_INFO_FORMS "Full Data"
vBioInfo = BioInfo(FirstName, MiddleName, Surname, BirthDate, BirthPlace, "Full Data")


(From Short Data form)

#define FORM_IS_SHORT_DATA "Short Data"
#define ALL_PERSONAL_INFO_FORMS "Short Data"
vBioInfo = BioInfo(FirstName, "", Surname, @Date, "", "Short Data")

Thanks Rick_R. Now I have something that I can work with.    Wondering if the programming in separate files have all the inbuilt SBasic commands and functions available? Such as xResultsetsearch( ), @xLookup ( ), @Left ( ), @IN ( ),  etc. ?

No offense intended, but I think you've over-complicated the answer. It's a simple matter of including something like this in the Global Code of each form:

#include "CDU_sbasic_include.sbas" 

That happens to be the name of my custom file that contains many of the subroutines and functions that I make heavy use of. If someone wants to use the sbas file that Lantica provides with Sesame, you they can use something like this in the Global Code:

#include "sbasic_include.sbas"
#include "CDU_sbasic_include.sbas" 

Then, you just move the appropriate programming into a text file with the .sbas extension, and make sure you change the name above to match. Just make sure that the #include line is near the top of the Global Code event, before any other commands.

"No offense intended, but I think you've over-complicated the answer. It's a simple matter of including something like this in the Global Code of each form: #include programfile.sbas"

It's not that simple.  If the #include file never references fields or if every field referenced exists in every form that #includes the file, that will work.  But if even just one form does not use every field referenced, the compile will fail unless you use the conditional compilation code.

It's been awhile since I worked with this.  I don't recall if it fails when the application is first loaded or the first time you load the form that doesn't contain all fields referenced.  If I remember correctly, the error is triggered when you load the form.  I'm pretty sure Sesame compiles the form when it's loaded, not when the application is started.

I have most of my large code blocks in a separate #include file even though they are form-specific, because I don't like the snippet-based coding approach. But an example that would be more likely would be where you first code a "Details" form with a lot of fields and related code and then someone says, "You know, when we're updating a record [i.e., manually changing data using a form] (or "When we first input a record") we don't need all that. Make another form like the one we already use but remove fields A, B, F, etc."

You might even plan up front to do that. In fact, you might even wind up with three forms: (1) "usual" form, (2) "input new record" form, (3) "input legacy record" form.

Regarding #3, years ago I set up a database for a collection law firm.  I set up the input screens in the order in which data would usually be created--first the account comes in, then a lawsuit is prepared, then suit is filed, etc.  We also hired two temps to go through our paper files and input existing files.  The data in those files was in reverse chronological order.  So I wound up creating separate screens that started with the post-judgment information, then went to date and type of judgment, then back to date suit was filed, etc.  Once those files were entered we never used those screens again.  Often with legacy records a lot of the "intermediate" status fields are not needed, e.g., "Y/N Itemized account in file.  Y/N Client's affidavit that account is correct in file"

Bharat_Naik wrote on Jun 7^th, 2011 at 11:56pm:

Yes, you are correct. It will not improve the time it takes to compile. It can actually increase it if there is a lot of code that that particular form doesn't need. For this reason, I personally never use #include "sbasic_include.sbas" because of the increase overhead when a form first opens.

Thanks Mark for imparting a little wisdom in this topic as to how and when to use it.