MWAPI Standard~

From the FAQ: ( as documented by Daniel P.B. Smith 1995)

---

11. Does M/MUMPS support Microsoft Windows and other Graphic User Interfaces (GUIs)?

M Windowing API (MWAPI)

A 1994 addition to the M standard, the M Windowing API (MWAPI), defines an interface between the M language and windowing systems.

InterSystems and Micronetics offer versions of M that implement the MWAPI in a Microsoft Windows environment. Digital has an implementation [is it commercially released? Details?] for Windows NT.

The M Windowing API and its commercial implementations are relatively new and have rough edges. The MWAPI has the advantage of portability and platform-independence, but has some limitations associated with the "least-common-denominator" approach.

A unique feature of the MWAPI is that this "API" does not consist of subroutine calls (except for a few incidental functions). MWAPI programming consists mainly of performing sets and kills into a "structured system variable," which looks like a standard M global. For example, to set the title of a window to "M Technology Demonstration," you write

    s ^$WINDOW("main","TITLE")="M Technology Demonstration"

To make its dimensions 300 by 200, you write

    s ^$WINDOW("main","SIZE")="300,200"

The MWAPI is currently offered for Microsoft Windows by InterSystems and Micronetics, and for Windows NT by Digital Equipment Corporation.  It is often presented as the windowing future for M technology.

VISUAL-BASIC-LIKE APPROACHES

InterSystems' "Visual M" is a set of tools which link M with Microsoft Visual Basic, creating an integrated dual-language environment. M code can be accessed and edited from within the VB design environment, can access VB control properties, and can be triggered by VB events.  

Micronetics product MSM-View Builder and MSM Workstation provides a Visual-Basic-like environment entirely based on M and the MWAPI.

"WRITE-SLASH" APPROACHES

InterSystems' "DT-Windows," MGlobal's MGM-PC (for MS-Windows) and MGM-Mac (for the Macintosh) use a feature of the M standard that allows the language to be extended for device-specific purposes by means of the "write-slash" syntax. In DT-Windows and MGM, the windowing system is treated as a "device" with an unusually rich repertoire of device-specific commands.  

Although DT-Windows and MGM are conceptually similar, they are incompatible with each other.  They are ad-hoc language extensions.  Neither seems to have set a defacto standard.  Why do these products (DT-Windows and MGM) provide a nonstandard approach?  The answer, in part, is that they were introduced prior to the finalization of the MWAPI standard.  Why do they still exist?  Because they are closer to their underlying windowing platform than the MWAPI, they arguably provide better performance and broader access to the GUI system's functionality.  

Examples from the DT-Windows manual and MGM product literature, respectively, show how an "OK" button is added to a dialog box:

DT-Windows

w /waddbutton(2,65,40,10,20,1,1,1,0,0,0,"OK",1)

MGM

W /DBUTTON("OK",2,9)

Paul Perrin said:
as far as practical use goes I find the write-slash formatvery useful for mumps integration within the MSWindows enviroment. Enabling data from a Mumps system (maybe from a DDP link to another hardware platform) to be placed on the windows clipboard for pasting into other applications is invaluable.

I've recently been using this mechanism to allow editing of DTM code using a windows based programmers editor (tho' I'm still experimenting)

From Memory:-

R "Routine Name:",ROUT W !
I ROUT="" Q
S SOURCE=$ZRS(ROUT)
I SOURCE="" Q
O 40 U 40 W /WSETCLIP(SOURCE)

; Prog can now paste code into windows editor
; Edit source
; Copy modified code back to clipboard

W "Hit <space> to reload source" R *X
I X'=$A(" ") Q

; Request Clipped Data, Get Response Message, If not null zsave
W /WGETCLIP
F I=1:1:10 W /WGETMESSAGE(.X) Q:X'=""  H .5
I X="" Q
S SOURCE=$P(X,$C(22),5)

ZS @ROUT:SOURCE:1
Q

Probably the shortest program editor I've ever written :-).