Search Results for input

 

Public Method

A Public Method may be called from any other Procedure, by the Default plug-in, or a Custom COM DLL. Each Public Method may either use specific Input Parameters, or it may accept an Input Query.

 

Remote

Takes three parameters, Url, InputQuery, OutputQuery

 

[DatePicker]

No parameters, provides a user friendly date picker as the input field for a given Field.

 

 

ApplyLang$

Takes one parameter

 

AmPm$

Takes one parameter

 

[TQName]

Has no parameters

 

TRONLog

Takes one parameter, OutputText

 

TRON

Takes one parameter, FilePath

 

SaveFile

Takes two parameters, FileName, FileData

 

[Time] (Top Query)

Has no parameters

 

 

[DateTime] (Top Query)

Has no parameters

 

InStr%

Takes two parameters, Source, Match

 

ETableStream

Takes two parameters, ExcelTableData, Options

 

Lookup

Takes six parameters, FieldBase, Destination, Table, Alias, SourceField, IfLenFld

 

HttpsEnsure

Takes no parameters.

 

WithGroup

Takes six parameters, FieldBase, GroupByField, Destination, Action, Source, IfLenFld

 

SSReference

A command to help build spreadsheets

 

FixFields

Takes one parameter, a single character

 

InStrAny$

Takes two parameters, Source, Match

 

InStrAny%

Takes two parameters, Source, Match

 

InStr$

Takes two parameters, Source, Match

 

HtmlUpload

Takes seven parameters, Location, Mode, Prompt, Path, Class, Name, HelpText

 

RecoverHtml$

Takes one parameter, EscapedHTMLString, and returns the Unescaped Version of this string

 

IsValidAlias$

Takes one parameter, a Source value

 

[Pull] List of Fields from another Query

Takes up to three parameters, QueryName, FieldBase, FieldNames

 

[Max]

Accepts a numeric value as a parameter.

 

 

[MaxLen]

Accepts a numeric value as a parameter.

 

[Placeholder]

Accepts one parameter

 

[Min]

Accepts a numeric value as a parameter.

 

Learn More about Frontend Development

Prerequisites: This tutorial assumes that you have already set up a Category and Procedure if necessary. This page covers some of the basics that are involved in Front End development using the MOX language.

 

 

Overview for PHP Developers

This hands-on experience article is written by an experienced PHP developer, and serves as an overview to help you understand the similarities and differences.

 

 

Syntax and Builtin Values, Procedures and Code Documentation

The MOX language pays heritage to BASIC, but has been crafted for the specific type of work and environment that is demanded of Moxie.Build.

 

Table Report

Table Reports are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As a Report, the Procedure is expected to produce output to be displayed to the user.

 

Remote Method

A Remote Method may be called by any other Moxie system. It can be used to divide up a large system among a number of backend servers, or as a public API for 3rd parties. In order to call a Remote Method from MOX, the Remote statement is used.

 

ForEach

Takes a variable number of parameters, QueryName, MethodName, [Param1, [Param2, etc...]]

 

ProcECom

Takes one parameter, QueryName

 

NewEComQuery

Takes one parameter, QueryName

 

Table Action

Table Actions are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As an Action, the Procedure is expected to perform some sort of task, such as an automated set of updates to the Database Table.

 

[Time] (DB Field Attribute)

Has no parameters.

 

Message Handler

A Message Handler is only ever called by the Database on a Database Event. These Event Messages allow a Developer to intercept operations taking place on a per-record level and implement Event based business logic.

 

Record Report

Record Reports are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As a Report, the Procedure is expected to produce output to be displayed to the user.

 

Record Action

Record Actions are presented to the users of the Default Admin interface and are also intended to be made available in a dynamic way to users of a customized front end. As an Action, the Procedure is expected to perform some sort of task, such as an automated set of updates to the Database Record.