util_altKeyDown to allow user to choose between scrolling board and
dragging the hint rect when both are possible. add adjustYOffset;
make it and board_setYOffset more tolerant of out-of-bounds inputs and
use that to simplify calling code.
to allow user to confirm before every attempt. Users will learn to
set this when T650s are in the mix. Save a new preference, and up the
stream version. Up beta version. Add the preference both to the prefs
dialog and to the bluetooth connection (for guest) dialog, with both
impacting the same field in gamePrefs.
postEmptyEvent; pass transport type with incoming packets so they can
be rejected if not on expected channel (to stop IR, which is always
on, from injecting into a BT game); do BT work and fire timers even
when menu is down; don't let robot run until after board is drawn for
the first time; on startup, don't let robot run until after board is
drawn once. Up version to b3.
than main on top. focusOwner was saved based on front form but on
startup I tried to set it in the main form. This will need to be
merged into a branch based on the 4.2.1 release for a 4.2.1.
show connection type dialog unless more than IR is available and
supported, and then build the dropdown dynamically based on what's
compiled-in and available on the device. This means you don't see the
BT option at all if you don't have BT.
and use it to send and check for heartbeats over any transport.
Caller must supply a reset proc which is called when heartbeat hasn't
been received in too long. No changes required to comms protocol, but
that means the heartbeat interval is fixed at compile time: can't be
negotiated, and the two ends had better agree. Currently tested with
linux host and PalmOS guest, where only the first heartbeat failure is
recovered from. So there's some debugging to be done still.
it's needed, removing those passed into _init and _send. When client
is unable to connect to host, raise alert to user and give choice to
continue trying. Clear 'suspendBT' flag when user manually resends or
opens different game. Currently this happens only on guest's failure
to find registered SDP; should also extend to remote device not
running at all and to host failure to send to guest.
Otherwise use FrmSetFocus. This works around a bug where key event that
leaks through from parent dialog dismisses dialog (whereupon another comes
up, and eventually cursor is left flashing on parent.)