[OFF] Input/Info Requested

[Mark Wieder]

Bill-

Here's my VB-to-xtalk cheat sheet. Hope you find something useful in
it. The formatting looks all wonky to me today for some reason. I'm
not sure why. Everything used to line up nicely, but now it all seems
staggered. Let me know if you have trouble with it and I'll try to
reformat it again into something more useful.

-- 
-Mark Wieder
 mwieder at ahsoftware.net
-------------- next part --------------
Visual Basic-to-xTalk Cheat Sheet:

XTalk languages follow a natural-language approach. In general, statements are of the imperative form in which there is an implied second-person subject of the statement (you) and the verb is the first word of the line: "put value into container", "add 1 to someVariable", etc.

Thus the VB syntax in which some statements have an implied verb ("X=4" instead of "LET X=4") must be translated to xTalk syntax "put 4 into x".

lblTemperature.Text = 98.6		put 98.6 into field "lblTemperature"
xyz = xyz + 1				add 1 to xyz
let x = 3.14					put 3.14 into x

In most cases a direct translation of VB to xTalk is not the best way to code any given problem. As with any programming language, there are many ways to accomplish any task. Direct translation will provide the fastest way to get a project converted, but from there out a rethinkng of the code will provide code that executes faster in fewer lines, is more readable and maintainable, and may offer new insights into how to solve a problem.

Arrays: Arrays in xTalk are associative - the index may be, but does not need to be, numeric in order to access array elements. The VB array syntax arrayName(index) is replaced by arrayName[index]. There is no VB equivalent for a non-numeric array index.

arrayName(4) = "hello"			put "hello" into arrayName[4]
						put "hello" into arrayName["greeting"]
						put "bonjour" into arrayName["greeting",tCurrentLanguage]

The odd VB syntax of returning a value from a function (procedure) by assigning the value to the name of the procedure is replaced in xTalk by the more standard return keyword.

PROCNAME = someValue		return someValue

Similarities: xTalk, like VB, is not case-specific: somevariable is the same as someVariable, as are SOMEVARIABLE and sOmEvArIAblE. Unless explicitVars is set to true (enable variable checking in the menu) variables do not need to be declared before use. This is similar to VB's OPTION EXPLICIT. In xTalk single-word string literals should be, but in general do not have to be (unless explicitVars is true), quoted:

put red into tCurrentColor
put "black" into tCurrentColor
answer hello
answer "hello, sailor"

The following are not necessary in xTalk:
REDIM
LET
PI is already defined as a constant

The following VB constants map directly to the following xTalk keywords:

vbCRLF					return
vbKeyReturn				return
vbNewLine					cr
vbKeyBack					8
vbOKOnly					"OK"
vbNullString					empty
vbBlack					"black"
vbWhite					"white"
vbRed					"red"
vbBlue					"blue"
vbGreen					"green"
vbYellow					"yellow"
vbMagenta					"magenta"
vbCyan					"cyan"

more direct mapping:

' (comment indicator)			"--" or "#"
DIM X AS INTEGER			local x or global x
PROCEDURE SomeProc			function SomeProc
DO						repeat
WHILE					repeat while
WEND						end while
LOOP						end while
SELECT CASE				switch (use break statement between cases)
END SELECT				end switch
CASE ELSE					default
OPEN fileName as "x"			open file fileName
CLOSE "x"					close file fileName
OPTION EXPLICIT				explictVars
TRIM(SomeString)			word 1 to -1 of SomeString

The following VB keywords have no mapping:
ON ERROR					(use try/catch construct)

The following constructs have no direct equivalent:
WITH
END WITH
label:
GOTO label
dot notation:
	instead of "lblMyLabel.Height" use "the height of field "MyLabel"
Timer controls
	possibly use invisible buttons with "send 'Timer' to me in the interval of me milliseconds"
System and ActiveX controls in external libraries

VB screen coordinates are in Twips rather than in pixels. There are usually 15 twips per pixel, although this can vary depending on display characteristics.

SELECT CASE/CASE/CASE ELSE/END SELECT constructs are represented by the switch construct in xTalk The biggest difference is that individual case statements need "break" statements to separate them (as in C or java) and to keep the code from falling through into the next case. In VB different case items that should execute the same code are placed on the same line; in xTalk they are placed on separate lines.

	VB							xTalk
SELECT CASE tValue				switch tValue
  CASE 1						  case 1
    routine1						    routine1
							    break
  CASE 2, CASE 3					  case 2
							  case 3
    routine2						    routine2
							    break
  CASE ELSE					  default
    routine3						    routine3
END SELECT					end switch