fivedev/harbour-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

2006-06-22 11:58 UTC+0300 Chen Kedem <niki@actcom.co.il>

Browse Source
This commit is contained in:
Chen Kedem
2006-06-22 08:57:16 +00:00
parent 16450c2e30
commit 8bcfa08073
3 changed files with 355 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
harbour/ChangeLog
View File

@@ -8,6 +8,22 @@
2002-12-01 13:30 UTC+0100 Foo Bar <foo.bar@foobar.org>
*/
* try to enable raw mode for console stdin in W32
* harbour/source/rdd/dbfntx/dbfntx1.c
* code clean-up
2006-06-22 11:58 UTC+0300 Chen Kedem <niki@actcom.co.il>
* TODO
* Modify to include latests TODO and TOFIX entries,
removed completed tasks.
* doc/gtapi.txt
+ Add a section by Przemyslaw Czerpak (druzus/at/priv.onet.pl)
"How to get rid of unwanted console in Windows GUI applications"
2006-06-22 10:55 UTC+0100 Ryszard Glab <rglab//imid.med.pl>
* harbour.spec
* include/hbver.h
* updated to set version 0.46.2
* include/hbapi.h

239
harbour/TODO
View File

@@ -2,76 +2,225 @@
* $Id$
*/
=======================================================================
Harbour Project To-Do list
=======================================================================
Tasks for v.1 beta:
_______________________________________________________________________
-------------------
Topic Responsible developer(s)
=================================== =========================
Assign to: Jean-Francois Lefebvre (JFL)
Detail...: The following need to be added to the OO system:
Class Method, Multiple Constructor, Class init Support.
Status...: Open.
DBFCDX support Ryszard Glab
***
Remove #pragma pack() tricks ???
from rdd .h files.
Assign to: <nobody>
Detail...: 'SAVE TO' statement doesn't work like Clipper.
Status...: Is it still true?
OO system Jean-Francois Lefebvre (JFL)
Adding Class Method
Adding Multiple Constructor
Adding Class init Support
***
Integrate floating point methods to ???
avoid inequalities at 13 or more
decimals. See DETAILS_FLOAT below.
Assign to: <nobody>
Detail...: Is memofile support complete?
Status...: Is it still true?
Add missing 5.3 ord* functions. Brian Hays
OrdKeyVal and others are still in
dummy.prg. Move dbcmd.c
***
'SAVE TO' statement doesn't work ???
like clipper's. Is memofile
support complete?
[more info ???]
Assign to: Ryszard, Przemek
Detail...: Debugger with basic interface written in C - it's enough to
borrow Phil's work from xHarbour.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add missing preprocessor directives from CL5.3:
REINDEX: missing [NOOPTIMIZE]
SEEK: missing [LAST]
SET DESCENDING OFF
SET DESCENDING ON
SET SCOPE TO
SET SCOPETOP TO
SET SCOPEBOTTOM TO
SET VIDEOMODE TO
Status...: Open.
***
Assign to: <nobody>
Detail...: Add missing Clipper virtual memory functions.
Status...: Open.
***
Assign to: <nobody>
Detail...: TBrowse() implementation still has bugs.
Status...: Open.
=======================================================================
Tasks for v.1 release:
_______________________________________________________________________
----------------------
Rewrite filesys.c to use native platform ???
specific file I/O with unlimited number
of file handles, while maintaining
compatibility with the CA-Cl*pper legacy
handle numbering system. This either
involves adding a linked list for the
translation table, or we should state that
only handles 0-4 are number compatible.
[Optimization]
Assign to: <nobody>
Detail...: Rewrite filesys.c to use native platform specific file I/O
with unlimited number of file handles, while maintaining
compatibility with the CA-Cl*pper legacy handle numbering
system. This either involves adding a linked list for the
translation table, or we should state that only handles 0-4
are number compatible.
Status...: Open.
Optimize out the need for the PUSHNIL Ryszard Glab
opcode before each function call.
[Optimization]
***
Assign to: Ryszard
Detail...: Optimize out the need for the PUSHNIL opcode before each
function call.
Status...: Open.
=======================================================================
Tasks for after v.1 release:
_______________________________________________________________________
----------------------------
Assign to: <nobody>
Detail...: Dynamic multi-language compiler/runtime support.
Status...: Open.
Dynamic multi-language compiler/runtime ???
support
***
UNICODE support. ???
Assign to: <nobody>
Detail...: UNICODE support.
Status...: Open.
***
Assign to: <nobody>
Detail...: Multithreading support.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add support for INET sockets.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add support for virtual file handles and registering some
meta handles so it will be possible to make:
h := fopen( "gzip:/tmp/myarchive.gz", FO_WRITE )
fwrite( h, cData )
fclose( h )
or:
h := fopen( "tcp:some.host:port", FO_WRITE )
...
or:
h := fopen( "|lpr -PLaserJet", FO_WRITE )
...
or:
h := fopen( "gunzip /tmp/myarchive.gz|", FO_READ )
...
etc.
Status...: Open.
***
Assign to: Przemek
Detail...: Define multi platform platform API for GTs which can mix
graphics objects with standard text output. Now it's
possible in GTXWC, GTWVT and GTALLEG. This I will discuss
yet also with xHarbour developers.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add GTNET driver which will allow to run Harbour application
remotely. GTNET will be used on server side and on client
side any native GT driver.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add support for remotely controlled GUI objects so we will
be able to create GUI programs with GTNET.
Status...: Open.
***
Assign to: <nobody>
Detail...: Add NETRDD - meta RDD which will allow transport layer
between client application and server application with any
other chosen RDD driver. Idea similar to GTNET but for RDD
drivers - it's sth like ADS does.
Status...: Open.
***
Assign to: Przemek
Detail...: Extended HB_IT_POINTER. In practice we can give them the
same functionality as for objects and use them for fast
creation objects at C level. We can also add HB_VALTYPE()
function which will return the extended type name, f.e.
"WINDOW", "FONT", "SOCKET" or anything what 3-rd party
programmers may want to use. It will greatly simplify
writing some libraries.
Status...: Open.
=======================================================================
Harbour Project To-Fix list
=======================================================================
Assign to: Przemek
Detail...: Eliminate using hb_stackTopItem() it causes that HVM is not
safe for reentrant and automatic GC activation. To not
reduce the speed chance the indexes in HB_STACK structure to
give fastest access to the most last allocated item on the
stack.
Status...: Open.
***
Assign to: Przemek
Detail...: Clean vertical spacing in .ppo files. It's necessary to
strep leading blank lines from included files.
Status...: Open.
***
Assign to: Przemek
Detail...: Fix setting private base for code blocks created by macro
compiler. Maybe it should be bound with making CLEAR MEMORY
safe.
Status...: Open.
***
Assign to: <nobody>
Detail...: SQLRDD.
Status...: Open.
***
Assign to: Ryszard
Detail...: Hash.
Status...: Working on it.
***
Assign to: <nobody>
Detail...: Real strong typing in the compiler.
Status...: Open.
Multithreading support. ???
=======================================================================
Detail descriptions for Tasks:
_______________________________________________________________________
DETAILS_FLOAT
The building of the double in val.c is simply different than how it
gets created when coded in source or read from a dbf
See Harbour archives under the subject
Some numbers are not as equal as others

154
harbour/doc/gtapi.txt
View File

@@ -2,15 +2,10 @@
* $Id$
*/
Message: 18 Date: Fri, 14 May 1999 20:14:57 -0600
From: "Bil Simser" <bsimser@xxxx.xxxx
Subject: gt API for DOS, Windows and OS/2
GT API functions
================
By Bil Simser (Fri, 14 May 1999)
I'm finally done and none the sooner. Attached you'll find my
implementation of the gt API functions for Harbour.
gt API functions
----------------
Using the gt API requires two steps.
The gt API interface is kept in gtapi.c. This houses the gt API and
does not have any platform or compiler specific information. This file
@@ -102,5 +97,146 @@ If however you do feel it's a good start
the please check it in and start writing those other terminal functions
(DEVPOS, etc.)
By: Bil
Best regards,
Bil.
How to get rid of unwanted console in Windows GUI applications
==============================================================
By Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Do not use GTWIN :-)
GTWIN is a driver for users who wants to write CUI applications and
should give them all possible features. GUI libraries do not have to
use GT drivers if they don't need any GT functionality, or if they
don't want to give users support for standard Clipper/Harbour functions
which operate on GT resources.
Harbour application can work without any GT driver. In such case all
functions which operates on GT resources are redirected to meta GT
driver (GTNUL) which is part of RTL library. This driver makes all
operations on memory buffer and only OUTSTD()/OUTERR() output is sent
outside. All GT drivers inherits from GTNUL or from other GTs but in
the inheritance chain the first GT driver is always GTNUL.
Because there is no hard coded bindings between core code and other GT
drivers, then by default only GTNUL will be linked. So if you will want
to use some real 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:
REQUEST RDDSYS
Something like that is also done by Clipper. If you add to your code
RDDSYS symbol, then the default RDD will not be linked because your
RDDSYS will overload the default one (of course if it will be linked
before the one in core code). So it's enough to write something like:
ANNOUNCE RDDSYS
or:
PROC RDDSYS; RETURN
Both gives the same effect, and default RDD (DBFNTX) will not be linked.
Exactly the same I've done in GT subsystem. HB_GTSYS() makes exactly
the same job as RDDSYS() but for GT. This symbol is requested by core
code and in the module where it is defined it request default build GT
driver or if it's not set then default GT driver for given platform.
For Win32 it looks like:
ANNOUNCE HB_GTSYS
REQUEST HB_GT_WIN
This causes that normal console applications do not have to explicitly
request GT driver and the one set in the module with HB_GTSYS is always
linked. If you do not want to link the GT driver then you have to make
the same as for RDD and add to your code:
ANNOUNCE HB_GTSYS
or:
PROC HB_GTSYS; RETURN
In such case your final application will not have any GT driver. If you
want to use GTNUL as base, you should add:
REQUEST HB_GT_NUL
Though IMHO this request should be part of GUI library core code. You
can link with your application more then one GT driver. It's enough
that you add more lines with:
REQUEST HB_GT_<name>
For example, compile this code:
/*** t.prg ***/
REQUEST HB_GT_WIN
REQUEST HB_GT_WVT
PROC MAIN()
? HB_GTVERSION(), HB_GTVERSION(1)
TONE( 200, 3 )
TONE( 300, 3 )
TONE( 500, 3 )
INKEY( 0 )
RETURN
and link it as Windows GUI application. Then simply execute:
t //GTWIN
and:
t //GTWVT
Most of Windows linkers execute startup initialization code in the
order of linked modules, so the first linked GT driver will be the
default one. But you can control it also from your application, by
defining HB_GT_DEFAULT_<name> symbol (I do not like this name because
it cannot be used with 10 character symbols so I'm ready for any other
positions). For example, if you add to your code:
ANNOUNCE HB_GT_DEFAULT_NUL
or:
PROC HB_GT_DEFAULT_NUL; RETURN
Then GTNUL will be the default GT driver, and even if you would not
disable GTWIN and link it with you 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, and when you'll want to enable debug
messages, you simply run:
myprog //GTWIN
and debug messages will use the GTWIN console window. You can think of
other situations when it could be useful to have full functional GT
driver in GUI application. You can even create mixed GUI/CUI code in one
program.
And finally, the TONE() function problem.
Low level TONE code is part of GT driver. In the past, GUI libraries in
Windows were linked the whole GTWIN driver and only TONE were used. It
was possible because someone blocked GTWIN to work with application
linked as Windows GUI programs. Now, GTWIN can be used with any
applications, and I do not want reduce its functionality. So GUI
libraries which needs TONE should have their own GT driver which will
support it. Now, such GT driver can also give much more features for
final users, because it allow to integrate GUI library with standard
Clipper screen functions.
How to create such base GUI GT driver?
It's enough take current GTWIN or GTWVT code and remove 90% of the code
from it. That is all, well almost, you have to also set new GT name.
You can use the following as a base for your new GT driver:
TODO: add location of the sample GT driver [Chen]
Best regards,
Przemek