Class lwv.bld

Object
   |
   +--lwv.bld

class lwv.bld

Contains the lwv.bld object.
Defined in lwvbld.js

Version:

• 2006-07-16 / JF

Field Detail

data

<static> Object data

Sends the specified data chars to the server. in Local Mode: sends to Parser. Redirected from lwk.inputField

lwv.bld

lwv.bld()

Builds the VT application. Contains the communication routines and links to global parts of the application.

Version:
• 2006-07-16 / JF

holdMode

<static> boolean holdMode(<boolean> value)

intelligent boolean accessor for Hold Mode flag.

Parameters:
value - optional: if true: do not peek to server. when changed: cancel / issue peek.

Returns:
if true: hold mode is active

isHostNode

<static> boolean isHostNode(<Node> fld)

Returns true, if the specified Node is a LogWeb VT host field. Checks if the node "is child of lwScreen".

Parameters:
fld - the Node under test

Returns:
true if the specified Node is a LogWeb host field.

See:
- lwh.current.isHostNode()

key

<static> void key(<String> str)

Sends the specified control char(s) to the server. in Local Mode: sends to Parser.

Parameters:
str - the String to send.

See:
- data

localMode

<static> boolean localMode(<boolean> value)

for tests: boolean accessor for Local Mode flag.

Parameters:
value - optional: if true: sends keyboard to parser.

Returns:
if true: local mode is active

singleStep

<static> boolean singleStep(<boolean> value)

for tests: boolean accessor for singleStep mode flag. If true: blocks received from server will be processed in single step mode. User may call receiveNext() or receive() (without any arguments) to process next token or rest of block. While the block is not completely processed, send requests will be buffered and PEEK is cancelled.

Parameters:
value - optional: the new value

Returns:
the (now) current value

strategy

<static> int strategy(<int> value)

int accessor: the display strategy.
it costs too much time to redisplay the screen for each char arriving. lwv.display, therefore, keeps an "updated" indicator per modified line, and waits for the VT application to call display.redraw() to show the cumulated effects on the screen. This is very effective, when called only once per block, but it does not give the visual "look and feel" of the hardware terminal: while internally processing a received data block, the screen does not change at all; only when processing is completely finished, the screen changes to its final contents.
This effect is very bad when scrolling lines.
We therefore let the user select one of the following display strategies to go closer to the hardware feeling (at the cost of performance):
• update screen once only after processing of each block.
  Is fastest, but does not show scrolling lines.
• update screen when scrolling lines (all lines deleted or inserted).
  Looks very good and still is quite fast; my favorite.
  Note: due to the limited resolution of setTimeout(), we cannot show more than ..30.. lines per second.
• update screen when a line is completely modified.
  This IS slower, but not sooo much better. I would not choose it.
• update screen whenever something is modified (for each data char).
  Nice "retro look", but VERY time consuming. OK, if I had a 5 MHz CPU minimum...

Parameters:
value - optional: the new display strategy:
0 = complete block only
1 = scrolling lines (inserted or deleted) - default
2 = completed lines (when row changes)
3 = each char (very slow!)

Returns:
the current strategy