[Harbour] SF.net SVN: harbour-project:[12781] trunk/harbour

[vouchcac]

Revision: 12781
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12781&view=rev
Author:   vouchcac
Date: 2009-10-29 02:16:21 + (Thu, 29 Oct 2009)

Log Message:
---
  * contrib/hbqt/hbqt_slots.cpp
  * contrib/hbqt/hbqt_slots.h

  * contrib/hbqt/qth/QAbstractItemModel.qth
  * contrib/hbqt/qtcore/QAbstractItemModel.cpp
  * contrib/hbqt/qtcore/TQAbstractItemModel.prg

  * contrib/hbxbp/xbpbrowse.prg
  * contrib/hbxbp/xbpdialog.prg
  * contrib/hbxbp/xbpgeneric.prg
  * contrib/hbxbp/xbphtmlviewer.prg
  * contrib/hbxbp/xbpparthandler.prg
  * contrib/hbxbp/xbpprintdialog.prg
  * contrib/hbxbp/xbpstatusbar.prg
  * contrib/hbxbp/xbptabpage.prg
  * contrib/hbxbp/xbptreeview.prg
  * contrib/hbxbp/xbpwindow.prg

  * contrib/hbxbp/tests/demoxbp.prg
% Fixes TO release memory properly.
! Only a small part is remaining FOR optimization and complete memory 
recovery.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/hbqt_slots.cpp
trunk/harbour/contrib/hbqt/hbqt_slots.h
trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp
trunk/harbour/contrib/hbqt/qtcore/TQAbstractItemModel.prg
trunk/harbour/contrib/hbqt/qth/QAbstractItemModel.qth
trunk/harbour/contrib/hbxbp/tests/demoxbp.prg
trunk/harbour/contrib/hbxbp/xbpbrowse.prg
trunk/harbour/contrib/hbxbp/xbpdialog.prg
trunk/harbour/contrib/hbxbp/xbpgeneric.prg
trunk/harbour/contrib/hbxbp/xbphtmlviewer.prg
trunk/harbour/contrib/hbxbp/xbpparthandler.prg
trunk/harbour/contrib/hbxbp/xbpprintdialog.prg
trunk/harbour/contrib/hbxbp/xbpstatusbar.prg
trunk/harbour/contrib/hbxbp/xbptabpage.prg
trunk/harbour/contrib/hbxbp/xbptreeview.prg
trunk/harbour/contrib/hbxbp/xbpwindow.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Search Mailing List?

[Jerry Finuliar]

Hi,

Is there a way to search through the mailing list archives? (of course except 
from downloading it)

Sorry for asking this silly question.

Thanks,
Jerry 



-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Re: hbmk2

[Viktor Szakáts]

while my file hwgui.lib is recompiled if I call:
c:>\project\hbmk2 sciwin.hbm
It don't relink the new lib. :(

Try dropping .lib extension from -l options.
They are unnecessary and may break the process
depending on the compiler you use.
[ See hbmk2 --help about that at -l option description. ]
If this doesn't help, please post your output
after adding -debuginc option.
Furthermore, which compiler/platform did you test this on?
Brgds,
Viktor

Hi,
MSVC 2008 is my compiler. Windows XP is my OS.
And I remove .lib extension of file .hbm.
And flag -debuginc makes no reference to the file hwgui.lib


There should be extra debug lines, which I was asking
you to post here.

I've found a few problems with some *nix platforms,
but MSVC 2008 works alright in my local tests.

It's possible you're using some non-hbmk2 ways to pass
lib dirs to MSVC linker (f.e. LIB or LIBPATH envvar),
and in this case hbmk2 has no way to find your libs for
dependency detection. If this is the case I suggest
to use -L option to pass lib dirs.

-debuginc output can give some clues.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Re: hbmk2

[Itamar Lins]

Viktor Szakáts escreveu:

Hi,


hbmk2 don't check if lib is more recent and not link again with new lib.
In my project my files is:
--->8--
-inc
-lhwgui.lib
-lhwg_qhtm.lib
-lprocmisc.lib
-lhbxml.lib
-gui
-run
--8<---
while my file hwgui.lib is recompiled if I call:
c:>\project\hbmk2 sciwin.hbm
It don't relink the new lib. :(


Try dropping .lib extension from -l options.
They are unnecessary and may break the process
depending on the compiler you use.

[ See hbmk2 --help about that at -l option description. ]

If this doesn't help, please post your output
after adding -debuginc option.

Furthermore, which compiler/platform did you test this on?

Brgds,
Viktor


Hi,
MSVC 2008 is my compiler. Windows XP is my OS.
And I remove .lib extension of file .hbm.
And flag -debuginc makes no reference to the file hwgui.lib

Best regards,
Itamar M.Lins Jr.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] hbmk2

[Viktor Szakáts]

Hi,

hbmk2 don't check if lib is more recent and not link again with new  
lib.

In my project my files is:
--->8--
-inc
-lhwgui.lib
-lhwg_qhtm.lib
-lprocmisc.lib
-lhbxml.lib
-gui
-run
--8<---
while my file hwgui.lib is recompiled if I call:
c:>\project\hbmk2 sciwin.hbm
It don't relink the new lib. :(


Try dropping .lib extension from -l options.
They are unnecessary and may break the process
depending on the compiler you use.

[ See hbmk2 --help about that at -l option description. ]

If this doesn't help, please post your output
after adding -debuginc option.

Furthermore, which compiler/platform did you test this on?

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] hbmk2

[Itamar Lins]

Hi!
Mr Viktor Szakáts.

hbmk2 don't check if lib is more recent and not link again with new lib.
In my project my files is:
--->8--
-inc
-lhwgui.lib
-lhwg_qhtm.lib
-lprocmisc.lib
-lhbxml.lib
-gui
-run
--8<---
while my file hwgui.lib is recompiled if I call:
c:>\project\hbmk2 sciwin.hbm
It don't relink the new lib. :(

Best regards,
Itamar M. Lins Jr.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] ADS limits

[Viktor Szakáts]

Hi Przemek,


I was unable to find a index level limit in Harbour's DBFCDX driver
using the test.


Because it's not possible to exploit this problem in Harbour CDX
implementation.
If you are using ADS then you can try to use ADI indexes. Looking at
.ADI files with binary editor they seem to be slightly modified CDX
format. They allow to use different page set in header size and  
instead
of using page offsets in bytes they use page offsets as page number  
what

increase maximum index size from 2^32 to 2^32 * page_size. Exactly the
same trick I'm using in Harbour NTX and NSX RDDs if user set large  
file

support what increase maximum size for this indexes to 2^32 * 2^10 =
2^42 = 4TB.


If we're at it, can you give a short comparison between
NSX and CDX in Harbour? I can't recall such thing in the
past, but could be I just missed it.

All I know is that NSX stores keys in "compressed" format,
so the size (and traffic volume) is lower.

BTW, I migrated from NSX to CDX a few years ago, because
CDX had less bugs than NSX in Clipper (Six), plus Harbour
only knew CDX at the time. Maybe now it's time to move back.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Portable win .dll support

[Viktor Szakáts]

 * contrib/hbwin/win_dll.c
   % Deleted cDLL structure member.
   - Deleted __XHARBOUR__ guarded parts (related to C structure  
handling,
 probably never tested, plus it didn't look something mature  
anyway)


  ; TOFIX: win64 .dll support, strangely testdll gives slightly
   different results for BCC and MSVC builds (and MINGW
   builds where it GPFs), also UNICODE isn't supported at all.
   So I guess Harbour .dll handling would better be rewritten.


Any takers for that?

[ I personally don't use .dlls, but it would so much
more elegant to provide this functionality properly and
across all win versions. Not to mention even win32 isn't
perfect. ]

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] ADS limits

[Przemysław Czerpak]

On Wed, 28 Oct 2009, Mindaugas Kavaliauskas wrote:

Hi,

> in the beginning I was going to write a private email to Przemek and
> ask about CDX detail, but more deep test gave me an answer.
> The problem of the customers was that sometimes browse does not show
> records (in scoped alias), but records for sure exist in database.
> We found that ORDKEYCOUNT() return zero but scope is not empty. The
> problem of ADS RDD is that it does not check return values of ADS
> API functions in many places, for exmaple, in processing of
> DBOI_KEYCOUNT.

Yes and as usually I always suggest to check error code and report them
if any as RT errors to catch problems as soon as possible and inform
user about them.

> Here AdsGetRecordCount() return error 7022.
> Advantage Error Guide:
> --
> 7022 Maximum index levels
> Problem: The current index is unbalanced. This problem is most
> likely to occur when using very long index keys and new keys are
> being added to the index. This error could also occur if the index
> is corrupt.

It may happen in CDX format when index key size is greater then
( 512 - 12 ) / 3 - 8 = 158. In such case maximum number of keys
in interior node is 2. It means that algorithms which do not
actively balance keys in pages during updates may store only
one key per page. Because in CDX format keys in interior nodes
are not real keys but only dummy key value then such key value
have to be repeated on each next level. In theory some algorithms
may end with infinite path from root to leaf page.
Well designed algorithm should not have such problems. CDX format
have bindings between pages on the same level so it's quite easy
to implement inter page key balancing and I implemented it in
Harbour. It causes that in Harbour for each three pages on the same
level only one may have 1 key and two others will have 2 keys so
for sure it has finite path from root node to key in the leaf.

> Solution: Reindex the file. The reindexed file will be built using
> the minimum number of levels. This will speed up all future
> operations using the index. If this does not resolve the problem,
> reindex with a larger page size (see Index Page Size, or see the API
> AdsReindex61 in the Advantage Client Engine Help or the method
> AdsIndexPageSize in the Advantage TDataSet Descendant Help). With a
> larger index page size, more keys will be stored in each page and
> will thus reduce the number of levels required. For specific
> equations showing the correlation between key and page size, see
> Index Key Size and Page Size Relationships.
> --

If you increase page size then more keys can be stored in single
node so even more primitive algorithms should not have problems
with degenerated tree though usually they will create indexes
noticeable bigger then optimal just after reindexation. If you
check size of CDX indexes updated record by record by Harbour
and other CDX drivers then you should find that indexes created
by Harbour are much smaller. Very often the size is comparable
to indexes created with [re]index command. It happens because
Harbour strongly balance keys in index pages during update with
some additional cost in write operation.

> Unfortunately CDX page size is fixed 512 and can not be changed. I
> have a database table from our customers. It has 50342 records only
> and index key length is 133 bytes. I have a feeling this is a too
> small limits for real life a database. Documented maximum key length
> is 240 bytes.

For such key length you can store 3 index keys in any index node.
If you can exploit this problem using such key then it means that
the CDX driver you are using does not have even basic key balance
for two neighbour pages because in such case it should keep 2 as
minimum keys for interior node so the maximum path from root node
to leaf for 2^32 records is 32.

> I had an idea that index tree level count can be limited by CDX
> structure, but after I've wrote a self contained test and compared
> ADSCDX and DBFCDX results, I understand it is a limit of ADS
> implementation. Both my real life key length 133, and a maximum
> documented key length 240 was tested (see test source below):
>   RDD: ADSCDX KeyLen:240 LASTREC():   6058 ORDKEYCOUNT(): 0
>   RDD: ADSCDX KeyLen:133 LASTREC(): 250052 ORDKEYCOUNT(): 0
> So, using a maximum documented key length (240 bytes) ADS can manage
> tables having only(!) 6058 records. The same results are for both
> 8.1 and 9.1 version of ADS.

So it's not good CDX implementation and probably the same code
is in all ADS clients.

> (512-some_header) / (240 + pointer_size) = 2 keys per page
> log(6058)/log(2+1)~= 7,927 ~= 8
> (512-some_header) / (133 + pointer_size) = 3 keys per page
> log(250052)/log(3+1)~= 8,966 ~= 9
> So, maximum index tree level in ADS is 8, or 9, or a little more, if
> index is unbalanced. Perhaps ADS uses a fixed length array to store
> pages in index navigation operations. I've not tested yet, if
> DB

Re: [Harbour] ADS limits

[Mindaugas Kavaliauskas]

Hi,


ToninhoFWi wrote:

I had this problem in the past and I change ads1.c to trap it:

2008-09-22 16:19 UTC-0300 Antonio Carlos Pantaglione

  * harbour/contrib/rddads/ads1.c
* using AdsCreateIndex61 when ADS_LIB_VERSION >= 610. This
functions use ADS_DEFAULT as index page size parameter and force
Advantage to compute a page size based on the key size to provide
optimal balancing.

Maybe I don't understand your problem or it is another problem than
mine, but using ADS 9.1 I never more have this problem. Try to change
ADS_DEFAULT from adsOrderCreate() in ads1.c to 1024 or more and see if
solve the problem.


Perhaps you use .adt/.adi tables/indices. CDX index page size is fixed 
to 512, and ADS docs says page size parameter is ignored for CDX. I use 
7.1 version, so, AdsCreateIndex61() is for sure used, but it does not help.



Regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] ADS limits

[ToninhoFWi]

Hi Mindaugas,

I had this problem in the past and I change ads1.c to trap it:

2008-09-22 16:19 UTC-0300 Antonio Carlos Pantaglione

  * harbour/contrib/rddads/ads1.c
* using AdsCreateIndex61 when ADS_LIB_VERSION >= 610. This
functions use ADS_DEFAULT as index page size parameter and force
Advantage to compute a page size based on the key size to provide
optimal balancing.

Maybe I don't understand your problem or it is another problem than
mine, but using ADS 9.1 I never more have this problem. Try to change
ADS_DEFAULT from adsOrderCreate() in ads1.c to 1024 or more and see if
solve the problem.

Regards,

Toninho.

__
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] will harbour run on present and future os for small device?

[Massimo Belgrano]

seem that Android is more good for native c application: Developer
Nathan Freitas has announced that the native C Tor application has
been successfully ported to Android, including an application that
"installs, runs and provides the glue needed to make it useful to end
users
2.0 sdk released http://developer.android.com/sdk/index.html
android ndk (1.6 jet) group http://groups.google.com/group/android-ndk

Hi hope in harbour convergence in future


--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] ADS limits

[Massimo Belgrano]

To direct access follow is right link
http://www.nntp.hk/web/devzone.advantagedatabase.com,Advantage.xHarbour.html


2009/10/28 Massimo Belgrano 

> I suggest you post also at advantage news group of [x]harbour
> That is very active
> You can access via web using follow
> http://www.nntp.hk/web/?server=devzone.advantagedatabase.com
> and choice advantage.xharbour
>
> or if works
>
> http://www.nntp.hk/web/head,devzone.advantagedatabase.com,Advantage.xHarbour.html
>
>
> 2009/10/28 Mindaugas Kavaliauskas :
>
> > Hi,
> >
> >
> > in the beginning I was going to write a private email to Przemek and ask
> > about CDX detail, but more deep test gave me an answer.
> >
> > The problem of the customers was that sometimes browse does not show
> records
> > (in scoped alias), but records for sure exist in database. We found that
> > ORDKEYCOUNT() return zero but scope is not empty. The problem of ADS RDD
> is
> > that it does not check return values of ADS API functions in many places,
> > for exmaple, in processing of DBOI_KEYCOUNT. Here AdsGetRecordCount()
> return
> > error 7022.
> >
> > Advantage Error Guide:
> > --
> > 7022 Maximum index levels
> >
> > Problem: The current index is unbalanced. This problem is most likely to
> > occur when using very long index keys and new keys are being added to the
> > index. This error could also occur if the index is corrupt.
> >
> > Solution: Reindex the file. The reindexed file will be built using the
> > minimum number of levels. This will speed up all future operations using
> the
> > index. If this does not resolve the problem, reindex with a larger page
> size
> > (see Index Page Size, or see the API AdsReindex61 in the Advantage Client
> > Engine Help or the method AdsIndexPageSize in the Advantage TDataSet
> > Descendant Help). With a larger index page size, more keys will be stored
> in
> > each page and will thus reduce the number of levels required. For
> specific
> > equations showing the correlation between key and page size, see Index
> Key
> > Size and Page Size Relationships.
> > --
> >
> > Unfortunately CDX page size is fixed 512 and can not be changed. I have a
> > database table from our customers. It has 50342 records only and index
> key
> > length is 133 bytes. I have a feeling this is a too small limits for real
> > life a database. Documented maximum key length is 240 bytes.
> >
> > I had an idea that index tree level count can be limited by CDX
> structure,
> > but after I've wrote a self contained test and compared ADSCDX and DBFCDX
> > results, I understand it is a limit of ADS implementation. Both my real
> life
> > key length 133, and a maximum documented key length 240 was tested (see
> test
> > source below):
> >  RDD: ADSCDX KeyLen:240 LASTREC():   6058 ORDKEYCOUNT(): 0
> >  RDD: ADSCDX KeyLen:133 LASTREC(): 250052 ORDKEYCOUNT(): 0
> > So, using a maximum documented key length (240 bytes) ADS can manage
> tables
> > having only(!) 6058 records. The same results are for both 8.1 and 9.1
> > version of ADS.
> >
> > (512-some_header) / (240 + pointer_size) = 2 keys per page
> > log(6058)/log(2+1)~= 7,927 ~= 8
> >
> > (512-some_header) / (133 + pointer_size) = 3 keys per page
> > log(250052)/log(3+1)~= 8,966 ~= 9
> >
> > So, maximum index tree level in ADS is 8, or 9, or a little more, if
> index
> > is unbalanced. Perhaps ADS uses a fixed length array to store pages in
> index
> > navigation operations. I've not tested yet, if DBSKIP() or DBSEEK() has
> also
> > the same limits, or it is a problem of ORDKEYCOUNT() only.
> >
> > I was unable to find a index level limit in Harbour's DBFCDX driver using
> > the test.
> >
> >
> > Regards,
> > Mindaugas
> >
> >
> > ---
> > #include "ads.ch"
> >
> > EXTERNAL ADS, DBFCDX
> > ANNOUNCE RDDSYS
> >
> > #define KEYLEN 240
> >
> > FUNC main()
> >  ADSSetFileType(ADS_CDX)
> >  ADSSetServerType(ADS_REMOTE_SERVER)
> >  ? "Press ESC to cancel"
> >  test("ADSCDX", "\\server\share\test176", KEYLEN)
> >  test("DBFCDX", "test176", KEYLEN)
> > RETURN 0
> >
> > PROC test(cRDD, cPath, nKeyLen)
> > LOCAL nI, nJ
> >  DBCREATE(cPath, {{"KEY", "C", nKeyLen, 0}}, cRDD, .T., "test")
> >  ORDCREATE(cPath, "key", "KEY")
> >  ? "Testing ", cRDD, "..."
> >  FOR nI := 1 TO 1000
> > FOR nJ := 1 TO 1000
> >   DBAPPEND()
> >   FIELD->KEY := REPLICATE(HB_MD5(STR(nI) + STR(nJ)), 8)
> > NEXT
> > IF ORDKEYCOUNT() != LASTREC()
> >   ? "RDD:", cRDD, "KeyLen:", nKeyLen, "LASTREC():", LASTREC(),
> > "ORDKEYCOUNT():", ORDKEYCOUNT()
> >   EXIT
> > ENDIF
> > ?? nI
> > IF INKEY() == 27
> >   EXIT
> > ENDIF
> >  NEXT
> >  DBCLOSEAREA()
> > RETURN
> >
> > ___
> > Harbour mailing list
> > Harbour@harbour-project.org
> > http://lists.harbour-pr

Re: [Harbour] ADS limits

[Massimo Belgrano]

I suggest you post also at advantage news group of [x]harbour
That is very active
You can access via web using follow
http://www.nntp.hk/web/?server=devzone.advantagedatabase.com
and choice advantage.xharbour

or if works
http://www.nntp.hk/web/head,devzone.advantagedatabase.com,Advantage.xHarbour.html


2009/10/28 Mindaugas Kavaliauskas :
> Hi,
>
>
> in the beginning I was going to write a private email to Przemek and ask
> about CDX detail, but more deep test gave me an answer.
>
> The problem of the customers was that sometimes browse does not show
records
> (in scoped alias), but records for sure exist in database. We found that
> ORDKEYCOUNT() return zero but scope is not empty. The problem of ADS RDD
is
> that it does not check return values of ADS API functions in many places,
> for exmaple, in processing of DBOI_KEYCOUNT. Here AdsGetRecordCount()
return
> error 7022.
>
> Advantage Error Guide:
> --
> 7022 Maximum index levels
>
> Problem: The current index is unbalanced. This problem is most likely to
> occur when using very long index keys and new keys are being added to the
> index. This error could also occur if the index is corrupt.
>
> Solution: Reindex the file. The reindexed file will be built using the
> minimum number of levels. This will speed up all future operations using
the
> index. If this does not resolve the problem, reindex with a larger page
size
> (see Index Page Size, or see the API AdsReindex61 in the Advantage Client
> Engine Help or the method AdsIndexPageSize in the Advantage TDataSet
> Descendant Help). With a larger index page size, more keys will be stored
in
> each page and will thus reduce the number of levels required. For specific
> equations showing the correlation between key and page size, see Index Key
> Size and Page Size Relationships.
> --
>
> Unfortunately CDX page size is fixed 512 and can not be changed. I have a
> database table from our customers. It has 50342 records only and index key
> length is 133 bytes. I have a feeling this is a too small limits for real
> life a database. Documented maximum key length is 240 bytes.
>
> I had an idea that index tree level count can be limited by CDX structure,
> but after I've wrote a self contained test and compared ADSCDX and DBFCDX
> results, I understand it is a limit of ADS implementation. Both my real
life
> key length 133, and a maximum documented key length 240 was tested (see
test
> source below):
>  RDD: ADSCDX KeyLen:240 LASTREC():   6058 ORDKEYCOUNT(): 0
>  RDD: ADSCDX KeyLen:133 LASTREC(): 250052 ORDKEYCOUNT(): 0
> So, using a maximum documented key length (240 bytes) ADS can manage
tables
> having only(!) 6058 records. The same results are for both 8.1 and 9.1
> version of ADS.
>
> (512-some_header) / (240 + pointer_size) = 2 keys per page
> log(6058)/log(2+1)~= 7,927 ~= 8
>
> (512-some_header) / (133 + pointer_size) = 3 keys per page
> log(250052)/log(3+1)~= 8,966 ~= 9
>
> So, maximum index tree level in ADS is 8, or 9, or a little more, if index
> is unbalanced. Perhaps ADS uses a fixed length array to store pages in
index
> navigation operations. I've not tested yet, if DBSKIP() or DBSEEK() has
also
> the same limits, or it is a problem of ORDKEYCOUNT() only.
>
> I was unable to find a index level limit in Harbour's DBFCDX driver using
> the test.
>
>
> Regards,
> Mindaugas
>
>
> ---
> #include "ads.ch"
>
> EXTERNAL ADS, DBFCDX
> ANNOUNCE RDDSYS
>
> #define KEYLEN 240
>
> FUNC main()
>  ADSSetFileType(ADS_CDX)
>  ADSSetServerType(ADS_REMOTE_SERVER)
>  ? "Press ESC to cancel"
>  test("ADSCDX", "\\server\share\test176", KEYLEN)
>  test("DBFCDX", "test176", KEYLEN)
> RETURN 0
>
> PROC test(cRDD, cPath, nKeyLen)
> LOCAL nI, nJ
>  DBCREATE(cPath, {{"KEY", "C", nKeyLen, 0}}, cRDD, .T., "test")
>  ORDCREATE(cPath, "key", "KEY")
>  ? "Testing ", cRDD, "..."
>  FOR nI := 1 TO 1000
> FOR nJ := 1 TO 1000
>   DBAPPEND()
>   FIELD->KEY := REPLICATE(HB_MD5(STR(nI) + STR(nJ)), 8)
> NEXT
> IF ORDKEYCOUNT() != LASTREC()
>   ? "RDD:", cRDD, "KeyLen:", nKeyLen, "LASTREC():", LASTREC(),
> "ORDKEYCOUNT():", ORDKEYCOUNT()
>   EXIT
> ENDIF
> ?? nI
> IF INKEY() == 27
>   EXIT
> ENDIF
>  NEXT
>  DBCLOSEAREA()
> RETURN
>
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>



-- 
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] bug: GTXWC and HB_GTI_WINTITLE

[Tamas TEVESZ]

On Wed, 28 Oct 2009, Przemysław Czerpak wrote:

 > >  > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
 > >  > doesn't seem to respect app CP (like now f.e. GTWVT does)
 > >  > with GTXWC, accented chars don't appear correctly in title
 > >  > bar.
 > >  > I tried to fix it by converting to UTF8 in gtxwc.c, but I
 > >  > may be missing something as it's still not right.
 > > this is a shot in the dark, but anyway.
 > > try adding
 > > XChangeProperty( wnd->dpy, wnd->window,
 > >XInternAtom( wnd->dpy, "_NET_WM_NAME", False ),
 > >XInternAtom( wnd->dpy, "UTF8_STRING", False ),
 > >8, PropModeReplace, wnd->szTitle, strlen( wnd->szTitle ));
 > > right after calling XStoreName() in gtxwc.c (line 2965).
 > 
 > It will work and in such case it should be enough to replace
 > XStoreName() with above XChangeProperty().
 > But I'm interesting why you used _NET_WM_NAME property instead
 > of WM_NAME used by XStoreName().

net_wm_hints is supposed to be a newer standard than wm_hints (and 
it's probably there for a reason). now, i don't know too much about x 
programming, but i suppose that everything alive now speak net_wm, so 
it just seemed natural.

 > Anyhow for final version I suggest to use XSetWMName() instead
 > of manually update properties:

according to the good old man, xsetwmname() sets wm_name, thus my 
manual way of setting net_wm_name instead.

but whichever you see fit, i guess. if wm_name works too, without side 
effects, then so be it.

 > 
 >if( wnd->fDspTitle )
 >{
 >   wnd->fDspTitle = FALSE;
 >   if( wnd->szTitle )
 >   {
 >  ULONG ulLen = hb_cdpStringInUTF8Length( wnd->hostCDP, TRUE, 
 > wnd->szTitle, strlen( wnd->szTitle ) );
 >  char * pBuffer = ( char * ) hb_xgrab( ulLen + 1 );
 >  XTextProperty text;
 > 
 >  hb_cdpStrnToUTF8( wnd->hostCDP, TRUE, wnd->szTitle, strlen( 
 > wnd->szTitle ), pBuffer );
 >  text.value = ( unsigned char * ) pBuffer;
 >  text.encoding = s_atomUTF8String;
 >  text.format = 8;
 >  text.nitems = strlen( pBuffer );
 >  XSetWMName( wnd->dpy, wnd->window, &text );
 >  hb_xfree( pBuffer );
 >   }
 >   else
 >  XStoreName( wnd->dpy, wnd->window, "" );
 >}
 > 
 > best regards,
 > Przemek
 > ___
 > Harbour mailing list
 > Harbour@harbour-project.org
 > http://lists.harbour-project.org/mailman/listinfo/harbour
 > 

-- 
[-]

mkdir /nonexistent
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] ADS limits

[Mindaugas Kavaliauskas]

Hi,


in the beginning I was going to write a private email to Przemek and ask 
about CDX detail, but more deep test gave me an answer.


The problem of the customers was that sometimes browse does not show 
records (in scoped alias), but records for sure exist in database. We 
found that ORDKEYCOUNT() return zero but scope is not empty. The problem 
of ADS RDD is that it does not check return values of ADS API functions 
in many places, for exmaple, in processing of DBOI_KEYCOUNT. Here 
AdsGetRecordCount() return error 7022.


Advantage Error Guide:
--
7022 Maximum index levels

Problem: The current index is unbalanced. This problem is most likely to 
occur when using very long index keys and new keys are being added to 
the index. This error could also occur if the index is corrupt.


Solution: Reindex the file. The reindexed file will be built using the 
minimum number of levels. This will speed up all future operations using 
the index. If this does not resolve the problem, reindex with a larger 
page size (see Index Page Size, or see the API AdsReindex61 in the 
Advantage Client Engine Help or the method AdsIndexPageSize in the 
Advantage TDataSet Descendant Help). With a larger index page size, more 
keys will be stored in each page and will thus reduce the number of 
levels required. For specific equations showing the correlation between 
key and page size, see Index Key Size and Page Size Relationships.

--

Unfortunately CDX page size is fixed 512 and can not be changed. I have 
a database table from our customers. It has 50342 records only and index 
key length is 133 bytes. I have a feeling this is a too small limits for 
real life a database. Documented maximum key length is 240 bytes.


I had an idea that index tree level count can be limited by CDX 
structure, but after I've wrote a self contained test and compared 
ADSCDX and DBFCDX results, I understand it is a limit of ADS 
implementation. Both my real life key length 133, and a maximum 
documented key length 240 was tested (see test source below):

  RDD: ADSCDX KeyLen:240 LASTREC():   6058 ORDKEYCOUNT(): 0
  RDD: ADSCDX KeyLen:133 LASTREC(): 250052 ORDKEYCOUNT(): 0
So, using a maximum documented key length (240 bytes) ADS can manage 
tables having only(!) 6058 records. The same results are for both 8.1 
and 9.1 version of ADS.


(512-some_header) / (240 + pointer_size) = 2 keys per page
log(6058)/log(2+1)~= 7,927 ~= 8

(512-some_header) / (133 + pointer_size) = 3 keys per page
log(250052)/log(3+1)~= 8,966 ~= 9

So, maximum index tree level in ADS is 8, or 9, or a little more, if 
index is unbalanced. Perhaps ADS uses a fixed length array to store 
pages in index navigation operations. I've not tested yet, if DBSKIP() 
or DBSEEK() has also the same limits, or it is a problem of 
ORDKEYCOUNT() only.


I was unable to find a index level limit in Harbour's DBFCDX driver 
using the test.



Regards,
Mindaugas


---
#include "ads.ch"

EXTERNAL ADS, DBFCDX
ANNOUNCE RDDSYS

#define KEYLEN 240

FUNC main()
  ADSSetFileType(ADS_CDX)
  ADSSetServerType(ADS_REMOTE_SERVER)
  ? "Press ESC to cancel"
  test("ADSCDX", "\\server\share\test176", KEYLEN)
  test("DBFCDX", "test176", KEYLEN)
RETURN 0

PROC test(cRDD, cPath, nKeyLen)
LOCAL nI, nJ
  DBCREATE(cPath, {{"KEY", "C", nKeyLen, 0}}, cRDD, .T., "test")
  ORDCREATE(cPath, "key", "KEY")
  ? "Testing ", cRDD, "..."
  FOR nI := 1 TO 1000
 FOR nJ := 1 TO 1000
   DBAPPEND()
   FIELD->KEY := REPLICATE(HB_MD5(STR(nI) + STR(nJ)), 8)
 NEXT
 IF ORDKEYCOUNT() != LASTREC()
   ? "RDD:", cRDD, "KeyLen:", nKeyLen, "LASTREC():", LASTREC(), 
"ORDKEYCOUNT():", ORDKEYCOUNT()

   EXIT
 ENDIF
 ?? nI
 IF INKEY() == 27
   EXIT
 ENDIF
  NEXT
  DBCLOSEAREA()
RETURN

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[12780] trunk/harbour

[Lorenzo Fiorini]

On Wed, Oct 28, 2009 at 10:12 AM,   wrote:

>  * contrib/hbxbp/tests/demoxbp.prg
>
>    ! Fixes to release objects in proper order.
>      Now demoxbp.exe terminates fine. Also you can
>      open as many dialogs as you want. Closing next dialog
>      releases the memory belonging to Qt objects but still
>      I have to investigate why whole of thread memory is not
>      released. So I have kept debug code intact. Just play with
>      current code, may be you can pin-point where Xbp*classes
>      need more tweaks.

Under Ubuntu 9.04 using QT from qtsoftware I still get a GPF at the end.

Starting program: /harbour-trunk/contrib/hbxbp/tests/demoxbp
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb59b3920 (LWP 21126)]
QPainter::begin: Widget painting can only begin as a result of a paintEvent
[New Thread 0xb081cb90 (LWP 21129)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb59b3920 (LWP 21126)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x081061a9 in ?? ()
#2  0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#3  0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#4  0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#5  0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#6  0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#7  0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#8  0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#9  0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#10 0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#11 0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#12 0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#13 0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#14 0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#15 0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#16 0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#17 0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#18 0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#19 0xb6153184 in hb_arrayGarbageRelease () from /opt/harbour/lib/libharbour.so
#20 0xb6122af9 in hb_gcRefFree () from /opt/harbour/lib/libharbour.so
#21 0xb613142b in hb_itemClear () from /opt/harbour/lib/libharbour.so
#22 0xb6133238 in hb_itemCopy () from /opt/harbour/lib/libharbour.so
#23 0xb6133a0f in hb_arraySet () from /opt/harbour/lib/libharbour.so
#24 0xb613cb45 in HB_FUN_msgSetData () from /opt/harbour/lib/libharbour.so
#25 0xb613102a in hb_vmSend () from /opt/harbour/lib/libharbour.so
#26 0xb612f457 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#27 0x08087bda in ?? ()
#28 0xb613102a in hb_vmSend () from /opt/harbour/lib/libharbour.so
#29 0xb612f457 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#30 0xb6130b15 in hb_codeblockEvaluate () from /opt/harbour/lib/libharbour.so
#31 0xb6130b9b in hb_vmDoBlock () from /opt/harbour/lib/libharbour.so
#32 0xb613102a in hb_vmSend () from /opt/harbour/lib/libharbour.so
#33 0xb6153337 in hb_arrayEval () from /opt/harbour/lib/libharbour.so
#34 0xb6159cff in HB_FUN_AEVAL () from /opt/harbour/lib/libharbour.so
#35 0xb6154a1a in hb_vmProc () from /opt/harbour/lib/libharbour.so
#36 0xb612dd34 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#37 0x08087bda in ?? ()
#38 0xb613102a in hb_vmSend () from /opt/harbour/lib/libharbour.so
#39 0xb612f457 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#40 0x08086cba in ?? ()
#41 0xb613102a in hb_vmSend () from /opt/harbour/lib/libharbour.so
#42 0xb612f457 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#43 0x0808669a in ?? ()
#44 0xb6154a1a in hb_vmProc () from /opt/harbour/lib/libharbour.so
#45 0xb612dd34 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#46 0x080866ca in ?? ()
#47 0xb6154a1a in hb_vmProc () from /opt/harbour/lib/libharbour.so
#48 0xb612dd34 in hb_vmExecute () from /opt/harbour/lib/libharbour.so
#49 0x080866fa in ?? ()
#50 0xb6154a1a in hb_vmProc () from /opt/harbour/lib/libharbour.so
#51 0xb6156014 in hb_vmInit () from /opt/harbour/lib/libharbour.so
#52 0xb615821e in main () from /opt/harbour/lib/libharbour.so
#53 0xb5e6c775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#54 0x08085d01 in ?? ()

best regards,
Lorenzo
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[12780] trunk/harbour

[vouchcac]

Revision: 12780
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12780&view=rev
Author:   vouchcac
Date: 2009-10-28 09:12:14 + (Wed, 28 Oct 2009)

Log Message:
---
2009-10-28 02:01 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
  * contrib/hbqt/hbqt_slots.cpp
  * contrib/hbqt/hbqt_slots.h
  * contrib/hbqt/moc_slots.cpp

  * contrib/hbqt/qtcore/QAbstractItemModel.cpp
  * contrib/hbqt/qtcore/TQAbstractItemModel.prg
  * contrib/hbqt/qth/QAbstractItemModel.qth

  * contrib/hbxbp/xbpbrowse.prg
  * contrib/hbxbp/xbpdialog.prg
  * contrib/hbxbp/xbpgeneric.prg
  * contrib/hbxbp/xbphtmlviewer.prg
  * contrib/hbxbp/xbplistbox.prg
  * contrib/hbxbp/xbprtf.prg
  * contrib/hbxbp/xbptabpage.prg
  * contrib/hbxbp/xbptreeview.prg
  * contrib/hbxbp/xbpwindow.prg

  * contrib/hbxbp/tests/demoxbp.prg

! Fixes to release objects in proper order.
  Now demoxbp.exe terminates fine. Also you can 
  open as many dialogs as you want. Closing next dialog
  releases the memory belonging to Qt objects but still
  I have to investigate why whole of thread memory is not 
  released. So I have kept debug code intact. Just play with 
  current code, may be you can pin-point where Xbp*classes 
  need more tweaks.

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbqt/hbqt_slots.cpp
trunk/harbour/contrib/hbqt/hbqt_slots.h
trunk/harbour/contrib/hbqt/moc_slots.cpp
trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp
trunk/harbour/contrib/hbqt/qtcore/TQAbstractItemModel.prg
trunk/harbour/contrib/hbqt/qth/QAbstractItemModel.qth
trunk/harbour/contrib/hbxbp/tests/demoxbp.prg
trunk/harbour/contrib/hbxbp/xbpbrowse.prg
trunk/harbour/contrib/hbxbp/xbpdialog.prg
trunk/harbour/contrib/hbxbp/xbpgeneric.prg
trunk/harbour/contrib/hbxbp/xbphtmlviewer.prg
trunk/harbour/contrib/hbxbp/xbplistbox.prg
trunk/harbour/contrib/hbxbp/xbprtf.prg
trunk/harbour/contrib/hbxbp/xbptabpage.prg
trunk/harbour/contrib/hbxbp/xbptreeview.prg
trunk/harbour/contrib/hbxbp/xbpwindow.prg


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error making harbour - ChangeLog 12778

[Alex Strickland]

Przemysław Czerpak wrote:


Please try again with current SVN code. Should be fixed at:
   2009-10-28 09:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)


It is fixed, and testax.prg works flawlessly, so does my hwgui test code.

Thank you once again.

Regards
Alex

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] SF.net SVN: harbour-project:[12779] trunk/harbour

[Viktor Szakáts]

Thank you very much (also to Tamas), after this patch
it's working perfectly.

Brgds,
Viktor

On 2009 Oct 28, at 09:13, dru...@users.sourceforge.net wrote:


Revision: 12779
 
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12779&view=rev
Author:   druzus
Date: 2009-10-28 08:13:41 + (Wed, 28 Oct 2009)

Log Message:
---
2009-10-28 09:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
 * harbour/src/rtl/gtxwc/gtxwc.c
   * use XSetWMName() instead of XStoreName() to set window title
 using UTF8 strings

 * harbour/include/hbapigt.h
   * always declare hb_gtIsGtRef() for C++ compiler

Modified Paths:
--
   trunk/harbour/ChangeLog
   trunk/harbour/include/hbapigt.h
   trunk/harbour/src/rtl/gtxwc/gtxwc.c


This was sent by the SourceForge.net collaborative development  
platform, the world's largest Open Source development site.

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour


___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] Error making harbour - ChangeLog 12778

[Przemysław Czerpak]

On Wed, 28 Oct 2009, Alex Strickland wrote:

Hi,

> With Harbour (Changelog: * $Id: ChangeLog 12778 2009-10-27 18:49:44Z druzus $)
> I did a SVN update this morning, "make clean", "make", and "make
> install". Only harbour.exe and hbpp.exe were copied to the bin
> directory (I discovered this trying to test testax.prg). I am using
> MSVC 2008.
> I then ran "make" again and I am getting the following make error:
> link.exe -nologo -dll -subsystem:console
> -libpath:../../../../../lib/win/msvc
> -out:"..\..\..\..\..\bin\win\msvc\harbour-20.dll"
> -implib:"../../../../../lib/win/msvc/harbour-20.lib" @__dyn__.tmp
> kernel32.lib user32.lib ws2_32.lib advapi32.lib gdi32.lib
>Creating library ../../../../../lib/win/msvc/harbour-20.lib and
> object ../../../../../lib/win/msvc/harbour-20.exp
> hvmall_dyn.obj : error LNK2019: unresolved external symbol
> _hb_gtIsGtRef referenced in function _hb_gcCollectAll
> ..\..\..\..\..\bin\win\msvc\harbour-20.dll : fatal error LNK1120: 1
> unresolved externals

Please try again with current SVN code. Should be fixed at:
   2009-10-28 09:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] SF.net SVN: harbour-project:[12779] trunk/harbour

[druzus]

Revision: 12779
  
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12779&view=rev
Author:   druzus
Date: 2009-10-28 08:13:41 + (Wed, 28 Oct 2009)

Log Message:
---
2009-10-28 09:13 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
  * harbour/src/rtl/gtxwc/gtxwc.c
* use XSetWMName() instead of XStoreName() to set window title
  using UTF8 strings

  * harbour/include/hbapigt.h
* always declare hb_gtIsGtRef() for C++ compiler

Modified Paths:
--
trunk/harbour/ChangeLog
trunk/harbour/include/hbapigt.h
trunk/harbour/src/rtl/gtxwc/gtxwc.c


This was sent by the SourceForge.net collaborative development platform, the 
world's largest Open Source development site.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Re: [Harbour] bug: GTXWC and HB_GTI_WINTITLE

[Przemysław Czerpak]

On Wed, 28 Oct 2009, Tamas TEVESZ wrote:

Hi,

>  > hb_gtInfo( HB_GTI_WINTITLE, "string with accented chars" )
>  > doesn't seem to respect app CP (like now f.e. GTWVT does)
>  > with GTXWC, accented chars don't appear correctly in title
>  > bar.
>  > I tried to fix it by converting to UTF8 in gtxwc.c, but I
>  > may be missing something as it's still not right.
> this is a shot in the dark, but anyway.
> try adding
> XChangeProperty( wnd->dpy, wnd->window,
>   XInternAtom( wnd->dpy, "_NET_WM_NAME", False ),
>   XInternAtom( wnd->dpy, "UTF8_STRING", False ),
>   8, PropModeReplace, wnd->szTitle, strlen( wnd->szTitle ));
> right after calling XStoreName() in gtxwc.c (line 2965).

It will work and in such case it should be enough to replace
XStoreName() with above XChangeProperty().
But I'm interesting why you used _NET_WM_NAME property instead
of WM_NAME used by XStoreName().
Anyhow for final version I suggest to use XSetWMName() instead
of manually update properties:

   if( wnd->fDspTitle )
   {
  wnd->fDspTitle = FALSE;
  if( wnd->szTitle )
  {
 ULONG ulLen = hb_cdpStringInUTF8Length( wnd->hostCDP, TRUE, 
wnd->szTitle, strlen( wnd->szTitle ) );
 char * pBuffer = ( char * ) hb_xgrab( ulLen + 1 );
 XTextProperty text;

 hb_cdpStrnToUTF8( wnd->hostCDP, TRUE, wnd->szTitle, strlen( 
wnd->szTitle ), pBuffer );
 text.value = ( unsigned char * ) pBuffer;
 text.encoding = s_atomUTF8String;
 text.format = 8;
 text.nitems = strlen( pBuffer );
 XSetWMName( wnd->dpy, wnd->window, &text );
 hb_xfree( pBuffer );
  }
  else
 XStoreName( wnd->dpy, wnd->window, "" );
   }

best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] Error making harbour - ChangeLog 12778

[Alex Strickland]

With Harbour (Changelog: * $Id: ChangeLog 12778 2009-10-27 18:49:44Z druzus $)

I did a SVN update this morning, "make clean", "make", and "make install". Only 
harbour.exe and hbpp.exe were copied to the bin directory (I discovered this 
trying to test testax.prg). I am using MSVC 2008.


I then ran "make" again and I am getting the following make error:

link.exe -nologo -dll -subsystem:console -libpath:../../../../../lib/win/msvc 
-out:"..\..\..\..\..\bin\win\msvc\harbour-20.dll" 
-implib:"../../../../../lib/win/msvc/harbour-20.lib" @__dyn__.tmp kernel32.lib 
user32.lib ws2_32.lib advapi32.lib gdi32.lib
   Creating library ../../../../../lib/win/msvc/harbour-20.lib and object 
../../../../../lib/win/msvc/harbour-20.exp
hvmall_dyn.obj : error LNK2019: unresolved external symbol _hb_gtIsGtRef 
referenced in function _hb_gcCollectAll
..\..\..\..\..\bin\win\msvc\harbour-20.dll : fatal error LNK1120: 1 unresolved 
externals


Regards
Alex
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour