Understanding Harbour GT

Understanding Harbour GT
HARBOUR GT SYSTEM - Terminal i/o.

Harbour handles clipper compatible terminal programming with its GT (Graphic Terminal)
system.
All Harbour terminal i/o goes to the high level GT, which is non-device specific. It then
goes to the selected terminal driver.
The Default
By default, Harbour will select the gtwin.lib. All GT commands will then be executed
through the functions in the gtwin.lib, which outputs
them to a WinXP console. Also, the next command pair are automatically included in your
Harbour app. You do not need to put in your program.
ANNOUNCE HB_GT_SYS
REQUEST HB_GT_WIN_DEFAULT
if you will want to use some GT you will have to add to your code:
REQUEST HB_GT_<name>
Setting the default GT driver is done exactly the same as setting the default RDD. In
RDD it request DBFNTX by default. It is done inside a
module with RDDSYS() symbol, and core code contains:
GT works with "console windows". and create several windows don't means that each routine will works
with a independent "console window".
A routine need to know how is it's "console window" to work.
In DBF you use SELECT to select a alias, in GT you use hb_gtSelect() to select a "console window".
SetGt() is a function to help to save/restore GT (or select a "console window" to work).
console window = window + keyboard + mouse
GT = GTWVG or any other GT
Note: "console window" here is not the same as "dos window".
Harbour build time GT driver and should not be replicated.

gtnul base GT driver from which each other inherits. It gives screen
buffer functionality but does not produce any screen output from
disp*() commands
Only outStd()/outErr() are supported.Its present on all platforms and i
always linked.
gtcgi very simple GT driver which does not make any output
formatting and simply sends it to stdout. Supported by all platforms.
gtstd it uses stdout output but tries to support full screen output but
without collor support and cursor shape. It format text to number of
row and columns if is able to detect these values on given platform.
Supported by all platforms.
gtpca Its PCANSI terminal GT it works in a way similar to ANSI GT
driver in Clipper though keyboard input is not fully supported. Now
GTTRM can make all GTPCA job and much more. Supported by all
platforms.
gtdos GT driver for DOS it uses BIOS and direct hardware screen
output so its very similar to Clipper one in practice due to the same
environment you will notice that all small details of Clipper GT drivers
are replicated here. You can think about it like 100% Clipper
compatible.
Supported only by DOS builds.
gtos2 GT driver for OS2 Its sth like GTWIN but for other OS.
Supported only by OS2 builds.
gtwin GT driver for MS-Windows console window. Supported only by
MS-WINDOWS (W95 or higher) builds.
GTQTC - GT driver Multiiplatform based on qt (win,linux,android,mac)
and support all feature of gt
gtcrs GT driver for platforms which supports curses or compatible
(ncurses) library in practice POSIX systems.Supported by POSIX
systems (mostly different *nixes)
gtsln GT driver for platforms which supports slang library. Its like
GTCRS but instead of CURSES it uses SLANG.Supported by POSIX
systems (mostly different *nixes).
It supports Unicode input/output if compiled with slang version which
also supports it.
gttrm its like GTCRS and GTSLN but it does not use any external
terminal library like SLANG or CURSES and it does not use
any external database to extract terminal capabilities so it can be
compiled on any POSIX system It will add support also for
DOS/Windows in the future. It should automatically detect UTF-8
terminal mode and switch internally to Unicode mode if necessary. In
theory is less functional then GTCRS and GTSLN because I hard coded
escape sequences only for few terminals but because I also added
support for some non standard terminal extensions and id one is using
a very limited set of output sequences, then it usually works better then
GTCRS and GTSLN.
Supported by POSIX systems (mostly different *nixes)
gtwvt GT driver for MS-Windows. It creates its own GUI window
instead of using MS-console window. It allows to change
font, window size, etc. Supported only by MS-WINDOWS (W95 or
higher) builds. Define using hb_gtInfo( HB_
It is a pure console implementation of traditional Clipper terminal taking
Windows API as its base console IO protocols. Its OI are
rendered in a Windows window and hence all of MSDN is available for
use with GTWVT.
To refresh the reader's memory , I must remind everybody that it is a
superb work of Peter Rees contributed to xHarbour on 22nd December
2003.
gtwvg is a GUI emulation of GTWVT for win, similar WVTGUI/GTWVT in
xHarbour but with more power, offers functions and classes to present a console
application looking like a windows one. It renderes GUI elements on top of Clipper
elements (GETS, BROWSERS, BOXES, LINES ) which gives the feel of Windows
elements. GTWVG can be used with existing code just adding some more code
but without sacrificing or modifying old one. Also all IO commands can be
rendered on top of the GUI elements GTWVG is meant to update your Clipper
code to have Windows look and feel without any code changes, just addition of
few lines.
Hybrid GUI mode is a quick path to convert existing code, and GTWVG is
developed on top of GTWVT.
NOW Xbase++ compatible controls can be hosted on CUI console. The

only requirement is that the parent of such GUI controls is an object created
with WvgCRT().
gtxwc GT driver for X-Window. Its like GTWVT but for nixes.
Additionaly it has set of predefined vector characters (box and arrowd
drawing characters) which can be used instead of the one defined in
font. It means that you will have all boxes and arrows you know from
DOS ans CP437 even if you chose a font which does not have them.
Additionally it support some simple graphic output. See
tests/gfx.prg for a simple program which demonstrates it. Supported by
POSIX systems (mostly different *nixes)
gtalleg- GT driver which uses alegro library for input/output. Its also
GUI driver which support HB_GFX*() drawing. Multi platform, works on
all platforms for which allegro library has been ported: MS-Win, DOS,
VESA, X11, FB, SDL,
gtgui pseudo GT driver which adds to GTNUL Clipboard and Tone
functionality. If you are using some MS-Windows GUI library
and you still want to use TONE() function or GTI_CLIPBOARD actions
then link this GT driver with your application.
If you do not want to use TONE() or GTI_CLIPBOARD then do not link it
it will be only waste of memory.
GTWVW was one of the first environments for porting Clipper

applications to Windows quickly and easily
checking ,about gtwvw, ChangeLog and/or SVN history, this error msg
has been placed there long time ago.
hb32\examples\gtwvw
need be recompiled becayse with
hbmk2 gtwvw.hbp
and play with sample at hb32\examples\gtwvw
Using harbour gt
Using non default terminal driver
To use an alternate driver, put these commands at the top of your main harbour prg
file. For example, to use the gtwvt.lib, which creates a real WinAPI window for the
output (rather than a simple console window) or gtwvg , use the following commands.
hbmk2 yourprg -gtwvt
hbmk2 yourprg -gtwvg
hbmk2 yourprg -gtqtc
Terminal driver with GUI

Add on GUI systems such as HWGUI and MiniGUI have their own terminal handling,
and may not need the older style clipper termio. However, to use the gtgui.lib, which
just supports Tone and Clipboard only, and can be used with a GUI addon product that
doesn't use console ouput, add these commands. As described in previous example,
you will need add -lgtgui.lib to hbmk2 parameters .
ANNOUNCE HB_GT_SYS
REQUEST HB_GT_GUI_DEFAULT
However, with add-on GUI systems it is possible to have a console window in

addition to the the GUI created windows. This may be useful for debugging, where you
could have some code in your Harbour program that sends text to the extra console
window. In that case you would want to be able to default to the GTGUI window, but
be able to invoke the GTWVT window at startup for debugging.
The GTNUL driver

GTNUL is a built-in driver that is always included with your app. You can specify
that you want no terminal i/o with the following commands.
However, this will also stop reading processing your keyboard, and if you do a read
or inkey(0), your app will hang.
ANNOUNCE HB_GT_SYS
REQUEST HB_GT_NUL_DEFAULT
Then GTNUL will be the default GT driver, and even if you would not disable GTWIN
and link it with your application, GTWIN will not be activated but GTNUL.
It could be intentional, because if your application is linked with more GTs, then you can
also set the default one when you start your application using //GT<name> switch, or
HB_GT environment variable. So you can create GUI application which will set the
default GT driver to NUL and will not activate GTWIN,
Mixing terminal Driver
You can include muliple drivers in your applications, and then choose the one you want
at startup time. In this case you should set one of the drivers as the default, and then
request that the other drivers be included in the link so the the default can be changed
at startup time. For example, use the next commands to create an application that
outputs to GTWVT by default, but can use GTWIN by specifying it at startup (or in
ANNOUNCE HB_GT_SYS
REQUEST HB_GT_WIN
REQUEST HB_GT_WVT_DEFAULT
Example: Compile and run this test program, mostly by Przemek

in ..harbour\doc\gtapi.txt. Remember to add both gtwvt.lib and
gtgui.lib to link line. Also note that the bcc32 compiler needs
the -W switch on the command line to work in the following example.
/*** t.prg, Test of mixing terminal drivers ***/
ANNOUNCE HB_GT_SYS
REQUEST HB_GT_GUI_DEFAULT
REQUEST HB_GT_WIN REQUEST
HB_GT_WVT FUNCTION
MAIN()
? HB_GTVERSION(), HB_GTVERSION(1)
TONE( 200, 3)
TONE( 300, 3)
TONE( 500, 3)
INKEY( 5 )
RETURN NIL
/* end */
Now run the programs three times, like this:
t
t //GTWIN
t //GTWVT
The first time the app will use GTGUI and you will hear the tones but not see any screen
output. Five seconds later the program will stop. Note that if you put an INKEY(0) or
READ in the program, it would hang, because this driver has no keyboard control.
The second time you should get a console window with the version text, and the third
time you should get a real WinAPI window with different version text. With these
drivers, you can speed up the program exit by hitting a key.
HB_GT: You can also control startup with the HB_GT environment variable. For
example to choose GTWVT when you run t, do this:
SET HB_GT=GTWVT
Sample using multiple gt

ANNOUNCE HB_GTSYS
REQUEST HB_GT_STD
REQUEST HB_GT_CGI
REQUEST HB_GT_WWT
REQUEST HB_GT_WIN
REQUEST HB_GT_WVT_DEFAULT
#INCLUDE "HBGTINFO.CH"
PROC main()
hb_gtInfo( HB_GTI_FONTSEL, "courier new")
Hb_GtInfo( HB_GTI_FONTWIDTH, 10 )
HB_GTInfo( HB_GTI_FONTSIZE, 18)
Name=space(30)
@ 2,2 SAY "Name" GET name
Read
@ 3,2 SAY "Hello "+name
INKEY( 0 )
return
Other syntax
You can replace the above commands with Harbour function as follows:
Replace With
-------------------------- -----------------------
ANNOUNCE HB_GT_SYS PROC HB_GTSYS; RETURN
REQUEST HB_GT_WIN_DEFAULT PROC HB_GT_WIN_DEFAULT; RETURN
Sample template
REQUEST HB_GT_XWC_DEFAULT
proc main()
local cFont
hb_gtInfo( HB_GTI_FONTSEL, cFont := xFontSel() )
alert( "What do you think about it???;;" + cFont )
return
function xfontsel()
local hProcess, hStdOut, cFontSel, n
hProcess := hb_processOpen( "xfontsel -print",, @hStdOut
)
if hProcess != -1
cFontSel := space( 256 )
n := fread( hStdOut, @cFontSel, len( cFontSel ) )
cFontSel := left( cFontSel, n )
hb_processClose( hProcess )
fclose( hStdOut )
endif
return cFontSel
What is gtwtg?
Implemented: Xbase++ compliant SetAppWindow() function.
The function simulates a WvgCRT() window from current thread specific GT console
if the function is called without parameters and current thread has not posted any
application window. This facilitates hosting WVG*Gui controls on pure GT invoked
console
* contrib/gtwvg/wvgwnd.prg
+ Restructured: GTWVG at GUI space.
Xbase++ compatible controls can be hosted on CUI console.
The only requirement is that the parent of such GUI controls is an object created
with WvgCRT(). If there
is no object of type WvgCRT() is in sight, in case of a pure GT invoked console, a
WvgCRT() object is created and
current console window handle is assigned to it. This is achieved through
SetAppWindow() function which is called
if a control's parent is supplied as NIL, in accordance with Xbase++
documentation.
The events assigned and executed by such controls are not posted to inkey()
processing, instead, are executed directly.
Just before executing an assigned event, focus is imposed on GT console and
returned to GUI control after processing
the execution. This ensures that GT is always in focus while GUI control executes
an assignment.
+ Introduced: In accordance with console coordinate system, the positioning and size
parameters supplied at the time of
construction of GUI objects now support
aPos == { nRow, nColumn } and aSize == { nRows, nColumns }
protocol. This has been achieved by supplying all four values in negative. Thus
WVG engine checks for negativity of position
and size values and determines that coordinate system be interpreted as
row/column instead of x/y(s).
For example,
WvgPushButton( , , { -10, -2 }, { -3, -10 } )
call will render the push button at 10,2,13,12 console area in terms of rows and
columns.
These coordinates will be maintained with resizing of console, etc.
To extend this coordinate system a step further, the pos and size arrays can be
populated with code blocks evaluating
to a negative numeric value. This implimentation facilitates to ancor any GUI
control to a specific postion always. Thus,
WvgPushButton( , , { {|| -( maxrow()-3 ) }, -2 }, { -10, -3 } )
will always position push button on last row-3 of the console no matter how many
rows the console is resized to.
+ oWVG:SetColorFG/BG() now accept clipper color string and renders the

corresponding RGB color of active GT palette.
This facilitates the embedding of GUI controls on Clipper complaint screen colors.
Thus,
oStatic:setColorBG( "GR*" )
will render the background of text label as yellow.
IMPORTANT: The above concepts are on the top of existing ones so no current
functionality is lost.
* contrib/gtwvg/tests/demowvg.prg
* contrib/gtwvg/tests/wvgtbrowser.prg
* contrib/gtwvg/tests/wvgutilities.prg
* contrib/gtwvg/tests/wvgxbp.prg
+ Restructured: the code parts to demonstrate newly introduced GTWVG concepts.
Specialy look at main window's menu system, push buttons at the bottom. Also
look at
<Main Menu><Traditional><Browser - GTWVG - Threaded>.
This example is reworked entirely and is a testimony to GTWVG power.
NOTE: more changes and code shifting and simplifying is on the drawing board.
Hopefully code will get an an overhaul in coming days.
Sample template for gtwvg
you can easy convert your source to gui adding a similar
template so you can maintain your source whith little
modificationand then start adding gui element in systax
compatible with xbp but with vgw prefix
// hbmk2 sample.prg -gtwvg -gui
REQUEST HB_GT_WVG_DEFAULT
REQUEST HB_GT_WVG
function main
set color to "N/W,N/BG,,,N/W*"
cls
SETMODE(25,80)
hb_gtInfo( HB_GTI_ICONFILE, "sample.ico" )
hb_gtInfo( HB_GTI_WINTITLE, "Programm Title" )
Hb_GtInfo( HB_GTI_SELECTCOPY,.T.)
Hb_GtInfo( HB_GTI_RESIZABLE, .T. )
HB_GTINFO( HB_GTI_CLOSABLE, .T. )
HB_GTINFO( HB_GTI_RESIZABLE, .T. )
HB_GTINFO( HB_GTI_CODEPAGE, 255 )
Hb_GTInfo(HB_GTI_MOUSESTATUS, 1 )
screenHeight:= HB_GTINFO( HB_GTI_SCREENWIDTH, HB_GTINFO(
HB_GTI_DESKTOPWIDTH ) )
screenHeight:HB_GTINFO( HB_GTI_SCREENHEIGHT, HB_GTINFO(
HB_GTI_DESKTOPHEIGHT ) - 50 )
*SETMODE( GTINFO( GTI_DESKTOPROWS ) - 5, GTINFO( GTI_DESKTOPCOLS ) )
HB_GTInfo(HB_GTI_FONTNAME, "Courier New")
HB_GTInfo(HB_GTI_FONTQUALITY,HB_GTI_FONTQ_HIGH )
if screenWidth >= 1920
HB_GTInfo(HB_GTI_FONTSIZE, 40)
ELSEIF screenWidth >= 1600 // 1280 *960
elseif screenWidth >= 1280 // 1280 *960
HB_GTInfo(HB_GTI_FONTSIZE, 20) // 15*80=1200 36*25=900
elseif screenWidth >= 1024 // 1024*760
Hb_GtInfo( HB_GTI_FONTWIDTH, 12.5 )
elseif screenWidth >= 800
ELSE
ENDIF
// another intresting
// HB_GtInfo( HB_GTI_ISFULLSCREEN, .T. )
// hb_gtInfo( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_FONT )
return
gtqtc Universal gt
GTQTC is The most Complete Gt and is able to run on all plafrom where is aibable qt
grqtc include all GT features existing in other GTs so now it's probably the most completed GT and for
sure it's the most portable one and it can be used without HBQT,
Now I'm thinking about committing it but because it's pure QT code then it can be compiled for
platforms were we do not have any native graphic GT, i.e. Symbian, Android, RB10, etc. Even for
MacOSX and IPhones it should give much more native appearance then GTXWC. So I think about
committing it to Harbour
contrib code instead of updating HBQT. Of course you will be able to merge it with HBQT. I created
functions you can add to HBQT as replacement for HB_GTI_WIDGET and HB_GTI_DRAWINGAREA
GTQTC fills a wide-gap in using Harbour platform-independent without even changing the setup. Plus it
will provide a solid initiative for console mode programmers to turn to pure GUI and having a edge of
mixingGT and GUI screens. New GTQTC has the power to be run in MT mode flawlessly, a powerful
offering
Is Easy convert app compiled with GTQTC you need only linked it app, substituting GTWVT and all
worked very fin
hbmk2 -lgtqtc
2013-04-24 12:22 UTC+0200 Przemysaw Czerpak (druzus/at/poczta.onet.pl)
+ contrib/gtqtc/gtqtc.cpp
+ contrib/gtqtc/gtqtc.h
+ contrib/gtqtc/gtqtc.hbc
+ contrib/gtqtc/gtqtc.hbp
+ contrib/gtqtc/gtqtc.hbx
+ contrib/gtqtc/hbmk2_qtmoc.hb
* contrib/hbplist.txt
+ added new QT based GT driver: GTQTC.
This implementation is slightly based on GTQTC created by
Pritpal Bedi - many thanks.
Now GTQTC supports nearly all GT features existing in all other GTs,
i.e.
fullscreen mode:
hb_gtInfo( HB_GTI_ISFULLSCREEN, <lFullScreen> )
automatic fullscreen switch after ALT+ENTER:
hb_gtInfo( HB_GTI_ALTENTER, <lEnable> )
maximized mode controlled by user:
hb_gtInfo( HB_GTI_MAXIMIZED, <lEnable> )
clipboard selection with SHIFT + MouseLeftButton:
hb_gtInfo( HB_GTI_SELECTCOPY, <lEnable> )
terminal window resizing:
hb_gtInfo( HB_GTI_RESIZABLE, <lCanResize> )
both resize modes
a) change number of rowas and columns:
hb_gtInfo( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_ROWS )
b) keep number of rows and clomuns and update font size
hb_gtInfo( HB_GTI_RESIZEMODE, HB_GTI_RESIZEMODE_FONT )
blocking ALT+F4 and [X] window buttons:
hb_gtInfo( HB_GTI_CLOSABLE, <lCanClose> )
all cursor shapes and setting cursor blink rate:
hb_gtInfo( HB_GTI_CURSORBLINKRATE, <nMilliSec> )
window positioning in screen pixels:
hb_gtInfo( HB_GTI_SETPOS_XY, <aNewPosXY> ) -> <aPrevPosXY>
mouse positioning in screen pixels:
hb_gtInfo( HB_GTI_MOUSEPOS_XY ) -> <aPosXY>
full control on font behavior with:
a) box characters shown as predefined internally pixmapos:
hb_gtinfo( HB_GTI_FONTATTRIBUTE,
hb_bitOr( HB_GTI_FONTA_DRAWBOX,
hb_gtinfo( HB_GTI_FONTATTRIBUTE ) ) )
b) forcing fixed size font metric:
hb_bitOr( HB_GTI_FONTA_FIXMETRIC,
c) independent character cell clearing:
hb_bitOr( HB_GTI_FONTA_CLRBKG,
d) displaying control characters ( ASC( x ) < 32 ) in row form:
hb_bitOr( HB_GTI_FONTA_CTRLCHARS,
and many others like palette settings (HB_GTI_PALETTE), displaying pictures (HB_GTI_DISPIMAGE),
keyboard modifiers (HB_GTI_KBDSHIFTS),clipboard reading and setting (HB_GTI_CLIPBOARDDATA)
or icon and window title settings (HB_GTI_ICONFILE, HB_GTI_WINTITLE)
GTQTC also supports GFX graphic primitives (hb_gfx*()) and it operates on new Harbour extended
mouse and keyboard key codes.The console window is shown when some user outputs appears so
it can be linked with GT GUI application been invisible by default.
It's pure QT code so now is the most portable Harbour GT driver which can be used on platforms where
we haven't native any GT so far or current GTs like GTXWC do not have native appearance. Because it
uses only high level GUI interface then it should be quite easy to convert it to other GUI libraries, i.e. GTK
hbqt/tests/demoqtc.prg
at hbqt/tests/demoqtc.prg find a demonstration appln based on GTQTC having functionality of firing HbQt
widget in modal dialog plus GT specific actions. I
How use gtqtc with qtwidgets?
hbmk2 this.prg -gtqtc hbqtgui.hbc hbqtwidgets.hbc -run
#include "hbqtstd.ch"
procedure main ()
? "test gtxwc +hbqt
? hb_gtversion()
inkey(0)
callguitest()
? "Hello"
inkey(0)
return
FUNCTION CallGuitest()
LOCAL cOne, cTwo, cThree, cFour
LOCAL SAYLIST := {}
LOCAL GETLIST := {}
cOne := Space( 10 )
cTwo := Space( 10 )
cThree := Space( 10 )
cFour := Space( 10 )
@ 02, 05 Qsay "First: " Qget cOne
@ 03, 05 Qsay "Second:" Qget cTwo
QSET GETSFONT TO QFont( "Courier New", 14 )
HbQtSet( _QSET_LINESPACING, 10 )
QREAD LINESPACING "10"
// QApplication():exec()
RETURN NIL
Understanding multi gt
This issue will be addressed gradually.
Using an example in text mode, see how to use and gtwin gtwvt
the same application.
file: testgt.prg
procedure main ()
cls
? "Test"
INKEY (0)
return
Start compiling with the command:

hbmk2 testgt.prg
Run the program of the three following ways:
testgt
testgt / / gtwin
testgt / / gtwvt
The function of the / / gtwin and / / indicate which is gtwvt gt should be used in implementing the
program.
In all three cases, we have a window using gtwin. This is because it be the standard (default) and be the
one used in compiling this example. The / / gtwvt is ignored in this case, since not gtwvt is present.
Now change the example, as follows:
file: testgt.prg
request hb_gt_wvt
procedure main ()
cls
? "Test"
INKEY (0)
return
Here we add the line "request hb_gt_wvt", requesting the inclusion of gtwvt the compilation. But how did
not specify which gt default, the
gtwin continues as standard.
Compile and run the sample, as follows:
hbmk2 testgt.prg
testgt
testgt / / gtwin
testgt / / gtwvt
testgt: gt uses the default (gtwin)
testgt / / gtwin: Use gtwin

In both cases above, the result is the same.
testgt / / gtwvt: Use gtwvt
Here the / / gtwvt starts to work and we have a window created with
the gtwvt. See that is no longer a text window, but a window
graphics (with appearance of the text window).
Continuing with the subject, let's go back to our basic example:
file: testgt.prg
procedure main ()
cls
? "Test"
INKEY (0)
return
Compile as follows:
hbmk2 testgt.prg-gtwvt
The parameter-gtwvt gtwvt indicates that we want the default in the execution the program.
Run as follows:
testgt
Gtwvt will be used. To gtwin we use, we need to perform

application as follows:
testgt / / gtwin
For text-mode applications, can leave both the gtwin as gtwvt as standard. And using the / / gtwin and / /
gtwvt, we can gt specify which to use, regardless of the pattern.
In short, the compiled sample can be performed in two ways different, since we have two gt's (and gtwin
gtwvt) included in the compilation.
I know at this point, still can not see clearly how take advantage of this feature in MiniGUI, but things will
become clearer as we move in the matter.
Let's see how to apply the use of multi-gt in MiniGUI.
We will use two functions of the Harbour:
hb_gtCreate ()
hb_gtSelect ()
With the function hb_gtCreate, create a new window using gtwvt. The function returns a pointer, which we
will use the function hb_gtSelect, To select this window as the current window.
Let's use the example below. In fact, it is the skeleton of a customer base. But it is enough for the desired
goal.
--- --- Start of example

procedure main ()
while. t.
cls
@ 0,0 say "customer base"
2.0 @ prompt "inclusion"
4.0 @ prompt "change"
6.0 @ prompt "exclusion"
8.0 @ prompt "consultation"
@ 10.0 say "Choose an option"
menu to op
if op == 0
exit
elseif op == 1
inclusion ()
elseif op == 2
alteration ()
elseif op == 3
Delete ()
elseif op == 4
query ()
endif
ENDDO
return
function inclusao ()cls

? "Inclusion of customers'
INKEY (0)
return
function change ()
cls
? "Alteration of the customers"
INKEY (0)
return
function Delete ()
cls
? "Exclusion of customers"
INKEY (0)
return
function query ()
cls
? "Query client"
INKEY (0)
return
--- End of example ---
We are four main menu options: inclusion, change, delete, and

query.
Compile with the following command:
hbmk2 cadastro.prg-gtwvt
The purpose of this application is to convert text to graphic, but because it a large application (pretend it
is), the conversion must be in stages.
The first step in conversion is the migration from one home screen to graphics window. So here we go:
Include a line with the command below, in order to use resources of MiniGUI:
# Include " minigui.ch "
Convert the text-mode menu to a window in graphical mode:
procedure main ()
DEFINE WINDOW MainWindow;
AT 0.0;
WIDTH 800;
HEIGHT 600;
TITLE "customer base";
MAIN
DEFINE MAIN MENU
POPUP "Options"
ITEM "inclusion" ACTION inclusion ()
ITEM "change" ACTION alteration ()
ITEM "exclusion" ACTION Delete ()
ITEM "consultation" ACTION query ()
END POPUP
END MENU
END WINDOW
ACTIVATE WINDOW MainWindow
return
Since our application is very large (keep pretending that is), you can not convert it to any chart. So we
have to maintain the routines of inclusion, change, delete, and query in text until they can be converted to
graphics mode. Here comes gtwvt into action and the functions and hb_gtCreate hb_gtSelect.
We put the line below, requesting the presence of our gtwvt application:
request hb_gt_wvt
And the routine inclusion, change, delete, and query are modified as follows:
inclusion function ()
local TMP
Local pNewGT
pNewGT: hb_gtCreate = ("WVT")
TMP: = hb_gtSelect (pNewGT)
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function change ()
local TMP
Local pNewGT
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function Delete ()
local TMP
Local pNewGT
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function query ()
local TMP
Local pNewGT
cls
? "Query client"
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
Here is the code we use at the beginning of each routine in text mode:
With the function hb_gtCreate, create a new window in our system, using gtwvt. And hb_gtSelect
function, we selected this window so we can work with it.
And here's the code we use at the end of each routine:
pNewGT: = nil
hb_gtSelect (TMP)
We eliminate the new window we created with the function and hb_gtCreate gt to restore the previous,
using the value returned by the function hb_gtSelect (at the beginning of the routine).
Below is the complete code sample has changed:

request hb_gt_wvt
procedure main ()

AT 0.0;
WIDTH 800;
HEIGHT 600;
MAIN
DEFINE MAIN MENU

POPUP "Options"
END POPUP
END MENU
END WINDOW
return
function inclusao()
local TMP
Local pNewGT
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function change ()
local TMP
Local pNewGT

cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function Delete ()
local TMP
Local pNewGT

cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function query ()
local TMP
Local pNewGT

cls
? "Query client"
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
Compile as follows:
hbmk2 cadastro2.prg-ic: \ MiniGUI \ include-Lc-lminigui: \ MiniGUI \ lib-gtgui
Run the program and you have a graphics window. Choose an option menu and you will have a window
in text mode (using gtwvt). Close the window pressing ENTER.
Avoid clicking the X to close the window in text mode, in addition to not close the window, does it not to
close with ENTER. I need to do more tests to see the best way to deal with this inconvenience.
The developer will get you moving the windows to your application so graphic gradually.
Below is one more step in the process, where the window of inclusion changed from text mode to
graphic:

request hb_gt_wvt
procedure main ()
AT 0.0;
WIDTH 800;
HEIGHT 600;
MAIN
DEFINE MAIN MENU
POPUP "Options"
END POPUP
END MENU
END WINDOW
return
function inclusion ()
DEFINE WINDOW Window1;
AT 0.0;
WIDTH 640;
HEIGHT 480;
TITLE "Adding clients"
END WINDOW
ACTIVATE WINDOW Window1
return
function change ()
local TMP
Local pNewGT
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function Delete ()
local TMP
Local pNewGT
cls
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
function query ()
local TMP
Local pNewGT
cls
? "Query client"
INKEY (0)
pNewGT: = nil
hb_gtSelect (TMP)
return
These examples were very rough, but hopefully we have given an idea
basic how to use these resources Harbour.
Now it's going to put into practice and improving the process
-
Sincerely,
Marcos Antonio Gambeta
http://marcosgambeta.wordpress.com
http://harbourgtk.wordpress.com
http://harbourqt.wordpress.com
__._,_.___

Understanding Harbour GT

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Understanding Harbour GT

Cargado por

Copyright:

Formatos disponibles

Understanding Harbour GT

HARBOUR GT SYSTEM - Terminal i/o.

Harbour build time GT driver and should not be replicated.

NOW Xbase++ compatible controls can be hosted on CUI console. The

GTWVW was one of the first environments for porting Clipper

Terminal driver with GUI

However, with add-on GUI systems it is possible to have a console window in

The GTNUL driver

Mixing terminal Driver

Example: Compile and run this test program, mostly by Przemek

/*** t.prg, Test of mixing terminal drivers ***/

Sample using multiple gt

+ oWVG:SetColorFG/BG() now accept clipper color string and renders the

Start compiling with the command:

Now change the example, as follows:

testgt: gt uses the default (gtwin)

testgt / / gtwin: Use gtwin

testgt / / gtwvt: Use gtwvt

Gtwvt will be used. To gtwin we use, we need to perform

Let's see how to apply the use of multi-gt in MiniGUI.

We will use two functions of the Harbour:

--- --- Start of example

function inclusao ()cls

We are four main menu options: inclusion, change, delete, and

And here's the code we use at the end of each routine:

Below is the complete code sample has changed:

--- --- Start of example

DEFINE WINDOW MainWindow;

DEFINE MAIN MENU

ACTIVATE WINDOW MainWindow

pNewGT: hb_gtCreate = ("WVT")

? "Alteration of the customers"

pNewGT: hb_gtCreate = ("WVT")

pNewGT: hb_gtCreate = ("WVT")

hbmk2 cadastro2.prg-ic: \ MiniGUI \ include-Lc-lminigui: \ MiniGUI \ lib-gtgui

--- --- Start of example

También podría gustarte

/* t.prg, Test of mixing terminal drivers */