Subject Re: Grid Navigation
From Mervyn Bick <invalid@invalid.invalid>
Date Wed, 14 Feb 2018 10:55:57 +0200
Newsgroups dbase.getting-started

On 2018-02-12 9:23 PM, Mustansir Ghor wrote:
> Dear Mervyn
> Thank you for the solution but using CALLBACK with zero on knowledge on windows operating I am reluctant to use it. Perhaphs you can suggest me a literature to learn little on  winuser.h file, user32, kernel32 functions.

The little I know of using functions from the Windows API stems
initially from the article "Killer WinAPI" in the advanced topics in the

The rest was gleaned from messages in the newsgroups.  Believe me, I've
still got a long way to go.  Initially it was a case of "monkey see,
monkey do" but later googling the functions in the MSDN (Microsoft
Developer Network) gave me an insight into what was happening and why it

Winuser.h (C:\Program Files (x86)\dBASE\Plus11\Include\winuser.h)
contains a set of constants which are used to pass parameters to the API
functions.  It's as exciting to read as a telephone directory as all it
does is give names to numbers.  It does, however, make a program more
meaningful by using, say, (wParam = VK_RETURN or wParam = VK_TAB) rather
than (wParam = 13 or wParam = 9)

(C:\Program Files (x86)\dBASE\Plus11\Include\win32api.prg) contains
most, if not all, of the API functions that can be used with dBASE.
(The program was written a LONG time ago and Windows has evolved since
then.)  From the extern definitions you can see from which .dll they are
taken from.  Unfortunately the program gives no indication of what the
functions do. All the Windows functions can be taken into memory where
they are then available to dBASE by running the program but this is
rather overkill if one is only going to be using a couple of the

CALLBACK is a dBASE command that was introduced in dBASE Plus 8.  We've
always been able to execute Windows functions from dBASE by using the
extern command.  CALLBACK now allows us to tell Windows to use our
function in place of its own function in certain cases.  This allows us
to do things that were not possible before.  Restricting navigation to
specified grid columns is but one example.  Creating a spinbox which can
be set by rotating the mouse-wheel is another.  Trapping keys that are
ignored by the normal key and onKey events is quite simple using CALLBACK.

Initially dBASE published some code examples but they don't seem to be
included with the newer versions of dBASE.  The examples were very basic
and the examples I've posted in the newsgroups from time to time since
then give a better idea of what can be done with CALLBACK.

Ken devotes a chapter to CALLBACK in his dBASE Plus book.

> But as you see suggested I see the standard norm on a form  is to to use entryfield/combobox for adding and editing items that are being displayed in the grid.
> Consider the case where you were to add item and its qty as new item, its unit of sales and price being picked fom lookuprowset and amount to be calculated.
> In the above scenario, we can select item from combobox, enter qty in the entryfield, then select pushbutton add to add the new item into grid and bring focus back to item combobox. However how then we handle correction of item, or removal of item. I am still confused how user will react to these objects, will they use mouse or keyboard

If the combobox and entryfield are datalinked to the same rowset as the
grid then selecting a record in the grid will show the correct values in
the combobox and entryfield.  Use an Edit button to enable the edit and
a Save button to save the new value(s) and recalculate the other fields.

If you set the grid's cuatab property true the user will be able to move
to controls in the z-order by using the Tab key.   If you set the
combobox's autoDrop property true the list will open automatically as
the control gets focus.  The user will then be able to do all input from
the keyboard.  The mouse will, however, still be available if the user
wants to use it.