[Harbour] Ask for var2str(...) and str2var(...) pairs functions for harbour ...
Hi Harbour developers, I want to ask for var2str(...) and str2var(...) pairs functions (something that in Xbase++) for harbour Or does it already there in harbour ? Please point me in right direction ... Shum -- View this message in context: http://n2.nabble.com/Ask-for-var2str-and-str2var-pairs-functions-for-harbour-tp4484296p4484296.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbQT - c++ stub - GC : Some food for thoughts
Xavi-2 wrote: > > I'm going to try extented FM Stats with something like this .- > > HB_TRFM( char *pPtr = (char *)hb_xgrab( size ) ); > > or .- > > HB_TRFM( pObj = ( QTextDecoder* ) new QTextDecoder( hbqt_par_QTextCodec( 1 > ) ) ); > > In order to have in hb_out.log for HB_FM_STATISTICS .- > > > ... > Total memory allocated: 234123 bytes (4176 block(s)) > Warning, memory allocated but not released: 1020 bytes (2 block(s)) > Block 1 0xd88970 (size 200) MYFUNCTION(256), "200F200F ..." > myfile.c:256 [ char *pPtr = (char *)hb_xgrab( size ) ] > Block 2 0xe4a990 (size 200) QT_QTEXTDECODER(129), "200F200F ..." > qtcore.cpp:129 [ pObj = ( QTextDecoder* ) new QTextDecoder( > hbqt_par_QTextCodec( 1 ) ) ] > > > I think with this FM Stats do it more human-readable, at least for me I > find it useful. > I hope it can help you. > I am certanly poor in string handelling, especially formatting, on c++ levels. So I have to rely on what is shown in the sources. Only point it lacks is giving equal size to arguments. Now it cannot be analyzed as a data, but description only. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/hbQT-c-stub-GC-Some-food-for-thoughts-tp4483724p4484002.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Request for inet thing
Giancarlo Niccolai wrote: > > Hello ppl of Harbour; > > I don't follow regurarly the ML, but, in an "ego surfing" session, I > found this message from April White from last october: > > Thank you for dropping in, does not matter "ego surfing" or ... You are still remembered for your contributions. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/Request-for-inet-thing-tp4481080p4483995.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbQT - c++ stub - GC : Some food for thoughts
Pritpal,
I'm going to try extented FM Stats with something like this .-
HB_TRFM( char *pPtr = (char *)hb_xgrab( size ) );
or .-
HB_TRFM( pObj = ( QTextDecoder* ) new QTextDecoder( hbqt_par_QTextCodec( 1 ) )
);
In order to have in hb_out.log for HB_FM_STATISTICS .-
...
Total memory allocated: 234123 bytes (4176 block(s))
Warning, memory allocated but not released: 1020 bytes (2 block(s))
Block 1 0xd88970 (size 200) MYFUNCTION(256), "200F200F ..."
myfile.c:256 [ char *pPtr = (char *)hb_xgrab( size ) ]
Block 2 0xe4a990 (size 200) QT_QTEXTDECODER(129), "200F200F ..."
qtcore.cpp:129 [ pObj = ( QTextDecoder* ) new QTextDecoder(
hbqt_par_QTextCodec( 1 ) ) ]
I think with this FM Stats do it more human-readable, at least for me I find it
useful.
I hope it can help you.
Best regards,
--
Xavi
El 30/01/2010 3:12, Pritpal Bedi escribió:
Hello All,
What I did
Pulled code from hbMK2 and placed along hbIDE files
==
#include "hbapi.h"
#if defined( __cplusplus )
const char * __hbmk2_hbcppmm( void )
{
return "HBCPPMM";
}
void * operator new[]( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
HB_TRACE( HB_TR_ALWAYS, ( " void * operator new[]( size_t %i
)", nSize ) );
return hb_xgrab( nSize );
}
void * operator new( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
void * pPtr = hb_xgrab( nSize );
HB_TRACE( HB_TR_ALWAYS, ( " void * operator new( size_t %i )
%p", nSize, pPtr ) );
return pPtr;
}
void operator delete[]( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p )", ptr
) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p
)", ptr ) );
}
}
void operator delete[]( void * ptr, size_t )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p, size_t
)", ptr ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p,
size_t )", ptr ) );
}
}
void operator delete( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p %i)", ptr,
0 ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p
%i)", ptr, 1 ) );
}
}
void operator delete( void * ptr, size_t nSize )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( "void operator delete( void * %p, size_t
%i )", ptr, nSize ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p,
size_t )", ptr ) );
}
}
#endif
Included this file say, cppstub.cpp, in hbIDE.hbp.
Compiled hbIDE => hbmk2 hbide.hbp -l- -lpsapi -nohbcppmm
And under various sections of ideeditor.prg and HBQPlainTextEdit.cpp
I put tracelog. Mainly:
QT_G_FUNC( hbqt_gcRelease_HBQPlainTextEdit )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
Cargo;
if( p&& p->bNew )
{
if( p->ph&& p->pq )
{
const QMetaObject * m = ( ( QObject * ) p->ph )->metaObject();
if( ( QString ) m->className() != ( QString ) "QObject" )
{
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit
" ) );
delete ( ( HBQPlainTextEdit * ) p->ph );
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB", p->ph, (void *)(p->pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
if ( p->ph )
{
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit ph=%p
-0", p->ph ) );
delete( p->ph );
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit ph=%p
-1", p->ph ) );
}
//p->ph = NULL;
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "NO__rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB", p->ph, (void *)(p->pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "DEL_rel_HBQPlainTextEdit
Object already deleted!" ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "PTR_rel_HBQPlainTextEditObject
not created with - new" ) );
p->ph = NULL;
}
}
void * hbqt_gcAllocate_HBQPlainTextEdit( void * pObj, bool bNew )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
hb_gcAllocate( sizeof( QGC_POINTER_HBQPlainTextEdit ), hbqt_gcFuncs() );
p->ph = pObj;
p->bNew = bNew;
p->func = hbqt_gcRelease_HBQPlainTextEdit;
if( bNew )
Re: [Harbour] undefined reference to 'hb_stack'
ok Viktor
Thanks for the quick reply!
Brgds,
Leandro
--
From: "Viktor Szakáts"
Sent: Friday, January 29, 2010 11:39 PM
To: "Harbour Project Main Developer List."
Subject: Re: [Harbour] undefined reference to 'hb_stack'
Just delete '#include "hbvmopt.h"', it's an internal header, not needed.
Brgds,
Viktor
On 2010 Jan 30, at 02:34, Leandro Damasio wrote:
Hi
Attempting to build a program with the function below I receive the
following linkage error message:
undefined reference to `hb_stack'
The error is related to hb_retnint and hb_retni calls, because when I
ommit them the error message goes away.
What is wrong with the code please?
Thank you
Leandro
--
code (aseek.c)
#include "hbvmopt.h"
#include "hbapi.h"
#include "hbapiitm.h"
#include "hbvm.h"
#include "hbstack.h"
ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock,
BOOL bSoft , BOOL bExact, PHB_ITEM pMode );
HB_FUNC( ASEEK )
{
PHB_ITEM pArray = hb_param( 1, HB_IT_ARRAY );
PHB_ITEM pValue = hb_param( 2, HB_IT_ANY );
PHB_ITEM pBlock = hb_param( 3, HB_IT_ANY );
if( pArray && pValue )
{
BOOL bSoft = HB_ISLOG( 4 ) ? hb_parl ( 4 ): FALSE;
BOOL bExact = HB_ISLOG( 5 ) ? hb_parl ( 5 ): FALSE;
PHB_ITEM pMode = hb_param( 6, HB_IT_NUMINT );
hb_retnint( hb_arraySeek( pArray, pValue, pBlock, bSoft, bExact
,pMode ) );
}
else
hb_retni( 0 );
}
ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock,
BOOL bSoft , BOOL bExact, PHB_ITEM pMode )
{
...
}
/code (aseek.c)
hbide output console
Project [ 2DT ] Launch [ No ] Rebuild [ No ] Started [ 23:04:23 ]
Starting in: qt\4.5.3\bin : D:\2DL\FONTES\T_FONTES
hbmk2: Processando op‡äes do ambiente: -compiler=mingw
hbmk2: Processando arquivo de configura‡Æo: D:\HARBOUR\BIN\hbmk.cfg
hbmk2: Linha de comando do compilador Harbour: (interno)
(D:\HARBOUR\BIN\harbour.exe) -n2
D:/2DL/FONTES/T_FONTES/2DT.PRG -q -id:/harbour/include -iD:/2DL/INCLUDE/GENERAL
-iD:/2DL/INCLUDE/HB_2 -iD:/2DL/INCLUDE/2DWGUI
Harbour 2.1.0dev (Rev. 13736)
Copyright (c) 1999-2010, http://www.harbour-project.org/
hbmk2: Comando do compilador C/C++:
gcc.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
-Id:/harbour/include -ID:/2DL/INCLUDE/GENERAL -ID:/2DL/INCLUDE/HB_2 -ID:/2DL/INCLUDE/2DWGUI
2DT.c C:\Users\Leo\AppData\Local\Temp\hbmk_tz229x.c
hbmk2: Comando do Linkeditor:
gcc.exe 2DT.o
hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase -l2dsmart -lhbwin
-lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd
-lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx
-lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon
-lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32
-lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32
-lwininet -lhbpcre -lhbzlib -Wl,--end-group -oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw
-LD:/2DL/LIBS/2DWGUI -LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0xee): undefined
reference to `hb_stack'
D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0x113):
undefined reference to `hb_stack'
collect2: ld returned 1 exit status
hbmk2: Erro: Executando linkeditor. 1
gcc.exe 2DT.o
hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase -l2dsmart -lhbwin
-lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd
-lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx
-lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon
-lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32
-lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32
-lwininet -lhbpcre -lhbzlib -Wl,--end-group -oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw
-LD:/2DL/LIBS/2DWGUI -LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
Exit Code [ 7 ] Exit Status [ 0 ] Finished at [ 23:04:24 ] Done in [ 0.93
Secs ]
/hdide output console
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
__
[Harbour] hbQT - c++ stub - GC : Some food for thoughts
Hello All,
What I did
Pulled code from hbMK2 and placed along hbIDE files
==
#include "hbapi.h"
#if defined( __cplusplus )
const char * __hbmk2_hbcppmm( void )
{
return "HBCPPMM";
}
void * operator new[]( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
HB_TRACE( HB_TR_ALWAYS, ( " void * operator new[]( size_t %i
)", nSize ) );
return hb_xgrab( nSize );
}
void * operator new( size_t nSize )
{
if( nSize == 0 )
nSize = 1;
void * pPtr = hb_xgrab( nSize );
HB_TRACE( HB_TR_ALWAYS, ( " void * operator new( size_t %i )
%p", nSize, pPtr ) );
return pPtr;
}
void operator delete[]( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p )", ptr
) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p
)", ptr ) );
}
}
void operator delete[]( void * ptr, size_t )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p, size_t
)", ptr ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete[]( void * %p,
size_t )", ptr ) );
}
}
void operator delete( void * ptr )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p %i)", ptr,
0 ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p
%i)", ptr, 1 ) );
}
}
void operator delete( void * ptr, size_t nSize )
{
if( ptr )
{
HB_TRACE( HB_TR_ALWAYS, ( "void operator delete( void * %p, size_t
%i )", ptr, nSize ) );
hb_xfree( ptr );
HB_TRACE( HB_TR_ALWAYS, ( " void operator delete( void * %p,
size_t )", ptr ) );
}
}
#endif
Included this file say, cppstub.cpp, in hbIDE.hbp.
Compiled hbIDE => hbmk2 hbide.hbp -l- -lpsapi -nohbcppmm
And under various sections of ideeditor.prg and HBQPlainTextEdit.cpp
I put tracelog. Mainly:
QT_G_FUNC( hbqt_gcRelease_HBQPlainTextEdit )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
Cargo;
if( p && p->bNew )
{
if( p->ph && p->pq )
{
const QMetaObject * m = ( ( QObject * ) p->ph )->metaObject();
if( ( QString ) m->className() != ( QString ) "QObject" )
{
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit
" ) );
delete ( ( HBQPlainTextEdit * ) p->ph );
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB", p->ph, (void *)(p->pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
if ( p->ph )
{
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit ph=%p
-0", p->ph ) );
delete( p->ph );
HB_TRACE( HB_TR_ALWAYS, ( "YES_rel_HBQPlainTextEdit ph=%p
-1", p->ph ) );
}
//p->ph = NULL;
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "NO__rel_HBQPlainTextEdit
ph=%p pq=%p %i B %i KB", p->ph, (void *)(p->pq), ( int ) hb_xquery( 1001 ),
hbqt_getmemused() ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "DEL_rel_HBQPlainTextEdit
Object already deleted!" ) );
}
}
else
{
HB_TRACE( HB_TR_ALWAYS, ( "PTR_rel_HBQPlainTextEditObject
not created with - new" ) );
p->ph = NULL;
}
}
void * hbqt_gcAllocate_HBQPlainTextEdit( void * pObj, bool bNew )
{
QGC_POINTER_HBQPlainTextEdit * p = ( QGC_POINTER_HBQPlainTextEdit * )
hb_gcAllocate( sizeof( QGC_POINTER_HBQPlainTextEdit ), hbqt_gcFuncs() );
p->ph = pObj;
p->bNew = bNew;
p->func = hbqt_gcRelease_HBQPlainTextEdit;
if( bNew )
{
new( & p->pq ) QPointer< HBQPlainTextEdit >( ( HBQPlainTextEdit * )
pObj );
HB_TRACE( HB_TR_ALWAYS, ( " _new_HBQPlainTextEdit ph=%p %i
B %i KB", pObj, ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
}
return p;
}
HB_FUNC( QT_HBQPLAINTEXTEDIT )
{
HB_TRACE( HB_TR_ALWAYS, ( " HB_FUNC( QT_HBQPLAINTEXTEDIT )0" ) );
void * pObj = NULL;
if( hb_pcount() == 1 && HB_ISCHAR( 1 ) )
{
pObj = new HBQPlainTextEdit() ;
}
else if( hb_pcount() == 1 && HB_ISPOINTER( 1 ) )
{
pObj = new HBQPlainTextEdit( hbqt_par_QWidget( 1 ) ) ;
}
else
{
pObj = new HBQPlainTextEdit() ;
}
hb_retptrGC( hbqt_gcAllocate_HBQPlainTextEdit( pObj, true ) );
}
And got the result as:
HBQPlainTextEdit.cpp:146: HB_TR_ALWAYSHB_FUNC( QT_HBQPLAINTEXTEDIT )
0
cppstub.cpp:26: HB_TR_ALWAYS void * operator new( size_t 100 )
0x38ace78
cppstub.cpp:26: HB_TR_ALWAYS void * operator new( size_t 24 )
0x38acf40
HBQPlainTextEdit.cpp:139: HB_TR_ALWAYS
Re: [Harbour] undefined reference to 'hb_stack'
Just delete '#include "hbvmopt.h"', it's an internal header, not needed.
Brgds,
Viktor
On 2010 Jan 30, at 02:34, Leandro Damasio wrote:
> Hi
> Attempting to build a program with the function below I receive the following
> linkage error message:
> undefined reference to `hb_stack'
> The error is related to hb_retnint and hb_retni calls, because when I ommit
> them the error message goes away.
> What is wrong with the code please?
>
> Thank you
> Leandro
>
> --
>
> code (aseek.c)
>
> #include "hbvmopt.h"
> #include "hbapi.h"
> #include "hbapiitm.h"
> #include "hbvm.h"
> #include "hbstack.h"
>
> ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock, BOOL
> bSoft , BOOL bExact, PHB_ITEM pMode );
>
> HB_FUNC( ASEEK )
> {
> PHB_ITEM pArray = hb_param( 1, HB_IT_ARRAY );
> PHB_ITEM pValue = hb_param( 2, HB_IT_ANY );
> PHB_ITEM pBlock = hb_param( 3, HB_IT_ANY );
> if( pArray && pValue )
> {
> BOOL bSoft = HB_ISLOG( 4 ) ? hb_parl ( 4 ): FALSE;
> BOOL bExact = HB_ISLOG( 5 ) ? hb_parl ( 5 ): FALSE;
> PHB_ITEM pMode = hb_param( 6, HB_IT_NUMINT );
> hb_retnint( hb_arraySeek( pArray, pValue, pBlock, bSoft, bExact
> ,pMode ) );
> }
> else
> hb_retni( 0 );
> }
>
> ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock, BOOL
> bSoft , BOOL bExact, PHB_ITEM pMode )
> {
> ...
> }
>
> /code (aseek.c)
>
>
> hbide output console
>
> Project [ 2DT ] Launch [ No ] Rebuild [ No ] Started [ 23:04:23 ]
>
> Starting in: qt\4.5.3\bin : D:\2DL\FONTES\T_FONTES
> hbmk2: Processando op‡äes do ambiente: -compiler=mingw
> hbmk2: Processando arquivo de configura‡Æo: D:\HARBOUR\BIN\hbmk.cfg
> hbmk2: Linha de comando do compilador Harbour: (interno)
> (D:\HARBOUR\BIN\harbour.exe) -n2 D:/2DL/FONTES/T_FONTES/2DT.PRG -q
> -id:/harbour/include -iD:/2DL/INCLUDE/GENERAL -iD:/2DL/INCLUDE/HB_2
> -iD:/2DL/INCLUDE/2DWGUI
> Harbour 2.1.0dev (Rev. 13736)
> Copyright (c) 1999-2010, http://www.harbour-project.org/
> hbmk2: Comando do compilador C/C++:
> gcc.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
> -Id:/harbour/include -ID:/2DL/INCLUDE/GENERAL -ID:/2DL/INCLUDE/HB_2
> -ID:/2DL/INCLUDE/2DWGUI 2DT.c C:\Users\Leo\AppData\Local\Temp\hbmk_tz229x.c
> hbmk2: Comando do Linkeditor:
> gcc.exe 2DT.o hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase
> -l2dsmart -lhbwin -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
> -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd
> -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro
> -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32
> -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr
> -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib
> -Wl,--end-group -oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw
> -LD:/2DL/LIBS/2DWGUI -LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
> D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0xee): undefined
> reference to `hb_stack'
> D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0x113): undefined
> reference to `hb_stack'
> collect2: ld returned 1 exit status
> hbmk2: Erro: Executando linkeditor. 1
> gcc.exe 2DT.o hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase
> -l2dsmart -lhbwin -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
> -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd
> -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro
> -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32
> -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr
> -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib
> -Wl,--end-group -oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw
> -LD:/2DL/LIBS/2DWGUI -LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
>
> Exit Code [ 7 ] Exit Status [ 0 ] Finished at [ 23:04:24 ] Done in [ 0.93
> Secs ]
>
> /hdide output console
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] undefined reference to 'hb_stack'
Hi
Attempting to build a program with the function below I receive the following
linkage error message:
undefined reference to `hb_stack'
The error is related to hb_retnint and hb_retni calls, because when I ommit
them the error message goes away.
What is wrong with the code please?
Thank you
Leandro
--
code (aseek.c)
#include "hbvmopt.h"
#include "hbapi.h"
#include "hbapiitm.h"
#include "hbvm.h"
#include "hbstack.h"
ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock, BOOL
bSoft , BOOL bExact, PHB_ITEM pMode );
HB_FUNC( ASEEK )
{
PHB_ITEM pArray = hb_param( 1, HB_IT_ARRAY );
PHB_ITEM pValue = hb_param( 2, HB_IT_ANY );
PHB_ITEM pBlock = hb_param( 3, HB_IT_ANY );
if( pArray && pValue )
{
BOOL bSoft = HB_ISLOG( 4 ) ? hb_parl ( 4 ): FALSE;
BOOL bExact = HB_ISLOG( 5 ) ? hb_parl ( 5 ): FALSE;
PHB_ITEM pMode = hb_param( 6, HB_IT_NUMINT );
hb_retnint( hb_arraySeek( pArray, pValue, pBlock, bSoft, bExact ,pMode
) );
}
else
hb_retni( 0 );
}
ULONG hb_arraySeek( PHB_ITEM pArray, PHB_ITEM pValue, PHB_ITEM pBlock, BOOL
bSoft , BOOL bExact, PHB_ITEM pMode )
{
...
}
/code (aseek.c)
hbide output console
Project [ 2DT ] Launch [ No ] Rebuild [ No ] Started [ 23:04:23 ]
Starting in: qt\4.5.3\bin : D:\2DL\FONTES\T_FONTES
hbmk2: Processando op‡äes do ambiente: -compiler=mingw
hbmk2: Processando arquivo de configura‡Æo: D:\HARBOUR\BIN\hbmk.cfg
hbmk2: Linha de comando do compilador Harbour: (interno)
(D:\HARBOUR\BIN\harbour.exe) -n2 D:/2DL/FONTES/T_FONTES/2DT.PRG -q
-id:/harbour/include -iD:/2DL/INCLUDE/GENERAL -iD:/2DL/INCLUDE/HB_2
-iD:/2DL/INCLUDE/2DWGUI
Harbour 2.1.0dev (Rev. 13736)
Copyright (c) 1999-2010, http://www.harbour-project.org/
hbmk2: Comando do compilador C/C++:
gcc.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
-Id:/harbour/include -ID:/2DL/INCLUDE/GENERAL -ID:/2DL/INCLUDE/HB_2
-ID:/2DL/INCLUDE/2DWGUI 2DT.c C:\Users\Leo\AppData\Local\Temp\hbmk_tz229x.c
hbmk2: Comando do Linkeditor:
gcc.exe 2DT.o hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase
-l2dsmart -lhbwin -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
-lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr
-lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool
-lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm
-lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group
-oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw -LD:/2DL/LIBS/2DWGUI
-LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0xee): undefined
reference to `hb_stack'
D:/2DL/LIBS/2DSMART/lib2dsmart.a(ASEEK.o):ASEEK.C:(.text+0x113): undefined
reference to `hb_stack'
collect2: ld returned 1 exit status
hbmk2: Erro: Executando linkeditor. 1
gcc.exe 2DT.o hbmk_tz229x.o -mconsole -Wl,--start-group -l2dwgui -l2dbase
-l2dsmart -lhbwin -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage
-lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr
-lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool
-lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm
-lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group
-oD:/2DL/EXE/2DT.exe -Ld:/harbour/lib/win/mingw -LD:/2DL/LIBS/2DWGUI
-LD:/2DL/LIBS/2DBASE -LD:/2DL/LIBS/2DSMART
Exit Code [ 7 ] Exit Status [ 0 ] Finished at [ 23:04:24 ] Done in [ 0.93 Secs ]
/hdide output console
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13735] trunk/harbour
Thank you Przemek, I've reimplemented it this way.
BTW, I didn't see this msg on the list. I suspect
it was TP_ONTIME() related.
Brdgs,
Viktor
On 2010 Jan 29, at 20:34, Przemysław Czerpak wrote:
> On Fri, 29 Jan 2010, vszak...@users.sourceforge.net wrote:
>
> Hi Viktor,
>
>> 2010-01-29 20:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
>> * contrib/hbtpathy/telepath.prg
>>! Fixed "midnight bug" in several TP functions having timeout option
>> (it was wrong in all places).
>> Reported by AbeB.
>>; Please review/test, I didn't make _any_ testing whatsoever.
>
> For such usage we have hb_milliSeconds() functions which returns
> UTC time (if OS supports UTC time offset) in milliseconds which is
> not reset at midnight, i.e. example I sent today to this list:
>
> proc main()
> cls
> hb_idleAdd( {||
> static s_timer := 0
> local timer := hb_milliseconds()
> if timer - s_timer > 1000
>s_timer := timer
>hb_dispoutat( 0, 72, time() )
> endif
> return nil
> } )
> wait
> return
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
On 2010 Jan 29, at 18:41, Viktor Szakáts wrote: > Hi Pritpal, > HbQUI() will be fine. Will change it shortly. >>> >>> It is very vague this name? Perhaps include the term "Loader" or >>> "Load" will help us remember the full name of the class and what their >>> purpose in the future ... >>> >> >> Probably, it is scheduled to be deleted at all. >> Working on something portable, hopefully I will succeed. >> QtUiTools components consumes a wopping 30 mb of >> memory over and above the normal appl loading, >> a huge amount. I need to get rid of this. > > It could be serialized object saved to file (.hbv?), > or pre-compiled .hrb file, or even plain .prg > compiled on the fly. > > Both can probably be solved with reasonable amount > work without the need to invent a new file format, and > if you want to keep the UI designer of QT, there > can be an .ui to .hrb/.prg/.hbv converter utility. Ops it cannot be .prg because this would need inclusion of compiler lib in final applications. Anyhow the other are still options. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13737] trunk/harbour
Revision: 13737 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13737&view=rev Author: vszakats Date: 2010-01-29 20:30:19 + (Fri, 29 Jan 2010) Log Message: --- 2010-01-29 21:29 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbtpathy/telepath.prg % Using HB_MILLISECONDS() instead of SECONDS(). ! TP_RECVTO(), TP_FLUSH() fixed to honor -1 timeout. ; Please review. No tests made besides compiling and reviewing. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbtpathy/telepath.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13735] trunk/harbour
On Fri, 29 Jan 2010, vszak...@users.sourceforge.net wrote:
Hi Viktor,
> 2010-01-29 20:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * contrib/hbtpathy/telepath.prg
> ! Fixed "midnight bug" in several TP functions having timeout option
> (it was wrong in all places).
> Reported by AbeB.
> ; Please review/test, I didn't make _any_ testing whatsoever.
For such usage we have hb_milliSeconds() functions which returns
UTC time (if OS supports UTC time offset) in milliseconds which is
not reset at midnight, i.e. example I sent today to this list:
proc main()
cls
hb_idleAdd( {||
static s_timer := 0
local timer := hb_milliseconds()
if timer - s_timer > 1000
s_timer := timer
hb_dispoutat( 0, 72, time() )
endif
return nil
} )
wait
return
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: 24 hour wait loop in telephaty
Before midnight "Seconds() < nDone" will be false in this case. Maybe (untested): ... nDone := (Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) ) ... ... Seconds() + iif( nDone > MS_PERDAY, MS_PERDAY, 0) < nDone April > Date: Fri, 29 Jan 2010 11:13:23 -0800 > From: abe.b...@att.net > To: harbour@harbour-project.org > Subject: [Harbour] Re: 24 hour wait loop in telephaty > > > will this fix it? > > > #define MS_PERDAY (24*60*60*60*60) > > nDone := (Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) ) % MS_PERDAY > > > > > > AbeB wrote: > > > > Hi All, > > > > > > these lines (and similar ones) in contrib\hbtpathy\telepath.prg > > will cause in to wait 24 hours if executed before midnight. > > > > > > > >nDone := Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) > > > >DO WHILE tp_OutFree( nPort ) > 0 .AND. ; > > ( nTimeout < 0 .OR. Seconds() < nDone ) > > hb_IdleState() > >ENDDO > > > > how can this be fixed? > > any ideas? > > > > thanks, > > Abe > > > > > > > > > -- > View this message in context: > http://n2.nabble.com/24-hour-wait-loop-in-telephaty-tp4481630p4481850.html > Sent from the harbour-devel mailing list archive at Nabble.com. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13736] trunk/harbour
Revision: 13736 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13736&view=rev Author: vszakats Date: 2010-01-29 19:15:16 + (Fri, 29 Jan 2010) Log Message: --- 2010-01-29 20:14 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbtpathy/telepath.prg ! Fixed typo in commented code in prev commit. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbtpathy/telepath.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: 24 hour wait loop in telephaty
will this fix it? #define MS_PERDAY (24*60*60*60*60) nDone := (Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) ) % MS_PERDAY AbeB wrote: > > Hi All, > > > these lines (and similar ones) in contrib\hbtpathy\telepath.prg > will cause in to wait 24 hours if executed before midnight. > > > >nDone := Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) > >DO WHILE tp_OutFree( nPort ) > 0 .AND. ; > ( nTimeout < 0 .OR. Seconds() < nDone ) > hb_IdleState() >ENDDO > > how can this be fixed? > any ideas? > > thanks, > Abe > > > > -- View this message in context: http://n2.nabble.com/24-hour-wait-loop-in-telephaty-tp4481630p4481850.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13735] trunk/harbour
Revision: 13735 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13735&view=rev Author: vszakats Date: 2010-01-29 19:12:54 + (Fri, 29 Jan 2010) Log Message: --- 2010-01-29 20:11 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbtpathy/telepath.prg ! Fixed "midnight bug" in several TP functions having timeout option (it was wrong in all places). Reported by AbeB. ; Please review/test, I didn't make _any_ testing whatsoever. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbtpathy/telepath.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 24 hour wait loop in telephaty
Hi All, these lines (and similar ones) in contrib\hbtpathy\telepath.prg will cause in to wait 24 hours if executed before midnight. nDone := Seconds() + iif( nTimeout >= 0, nTimeout, 0 ) DO WHILE tp_OutFree( nPort ) > 0 .AND. ; ( nTimeout < 0 .OR. Seconds() < nDone ) hb_IdleState() ENDDO how can this be fixed? any ideas? thanks, Abe -- View this message in context: http://n2.nabble.com/24-hour-wait-loop-in-telephaty-tp4481630p4481630.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Hi Pritpal, >>> HbQUI() will be fine. >>> Will change it shortly. >> >> It is very vague this name? Perhaps include the term "Loader" or >> "Load" will help us remember the full name of the class and what their >> purpose in the future ... >> > > Probably, it is scheduled to be deleted at all. > Working on something portable, hopefully I will succeed. > QtUiTools components consumes a wopping 30 mb of > memory over and above the normal appl loading, > a huge amount. I need to get rid of this. It could be serialized object saved to file (.hbv?), or pre-compiled .hrb file, or even plain .prg compiled on the fly. Both can probably be solved with reasonable amount work without the need to invent a new file format, and if you want to keep the UI designer of QT, there can be an .ui to .hrb/.prg/.hbv converter utility. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Hi! Qt has an application (uic) to generate one CPP from the one UI... I believe that a viable solution would have something to import a hbIDE the UI and generate a PRG or we build an "hbqtuic" to obtain one PRG from a UI file. What do you think? Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13734] trunk/harbour
Revision: 13734 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13734&view=rev Author: druzus Date: 2010-01-29 17:35:08 + (Fri, 29 Jan 2010) Log Message: --- 2010-01-29 18:34 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbsocket.c * do not try to resolve NULL or empty addresses in hb_socketResolveAddr() Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/hbsocket.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Vailton Renato wrote: > >> HbQUI() will be fine. >> Will change it shortly. > > It is very vague this name? Perhaps include the term "Loader" or > "Load" will help us remember the full name of the class and what their > purpose in the future ... > Probably, it is scheduled to be deleted at all. Working on something portable, hopefully I will succeed. QtUiTools components consumes a wopping 30 mb of memory over and above the normal appl loading, a huge amount. I need to get rid of this. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13731-trunk-harbour-tp4477687p4481271.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13733] trunk/harbour
Revision: 13733 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13733&view=rev Author: vouchcac Date: 2010-01-29 17:27:16 + (Fri, 29 Jan 2010) Log Message: --- * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg * contrib/hbide/idedocks.prg * contrib/hbide/ideeditor.prg * contrib/hbide/idefindreplace.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideprojmanager.prg * contrib/hbide/idethemes.prg * contrib/hbqt/filelist.mk * contrib/hbqt/generator/qt45.qtp * contrib/hbqt/hbqt.h * contrib/hbqt/qtcore/filelist.mk + contrib/hbqt/qtcore/QBuffer.cpp + contrib/hbqt/qtcore/TQBuffer.prg + contrib/hbqt/qth/QBuffer.qth - contrib/hbqt/THbpQtUI.prg + contrib/hbqt/THbQtUI.prg * contrib/hbxbp/hbpprocess.prg * contrib/hbxbp/xbpfontdialog.prg * contrib/hbxbp/xbpgeneric.prg * contrib/hbxbp/xbphtmlviewer.prg * contrib/hbxbp/xbplistbox.prg * contrib/hbxbp/xbpmenubar.prg * contrib/hbxbp/xbpprintdialog.prg * contrib/hbxbp/xbpstatusbar.prg * contrib/hbxbp/xbptoolbar.prg * contrib/hbxbp/xbptreeview.prg * contrib/hbxbp/xbpwindow.prg -+ HbpQtUI => HbQtUI. ! Cleaned :pPtr := 0 => :pPtr := NIL + Implemented QBuffer() class which allows to load .u from .prg embedding or from database. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/idedocks.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/idefindreplace.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/idethemes.prg trunk/harbour/contrib/hbqt/filelist.mk trunk/harbour/contrib/hbqt/generator/qt45.qtp trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/qtcore/filelist.mk trunk/harbour/contrib/hbxbp/hbpprocess.prg trunk/harbour/contrib/hbxbp/xbpfontdialog.prg trunk/harbour/contrib/hbxbp/xbpgeneric.prg trunk/harbour/contrib/hbxbp/xbphtmlviewer.prg trunk/harbour/contrib/hbxbp/xbplistbox.prg trunk/harbour/contrib/hbxbp/xbpmenubar.prg trunk/harbour/contrib/hbxbp/xbpprintdialog.prg trunk/harbour/contrib/hbxbp/xbpstatusbar.prg trunk/harbour/contrib/hbxbp/xbptoolbar.prg trunk/harbour/contrib/hbxbp/xbptreeview.prg trunk/harbour/contrib/hbxbp/xbpwindow.prg Added Paths: --- trunk/harbour/contrib/hbqt/THbQtUI.prg trunk/harbour/contrib/hbqt/qtcore/QBuffer.cpp trunk/harbour/contrib/hbqt/qtcore/TQBuffer.prg trunk/harbour/contrib/hbqt/qth/QBuffer.qth Removed Paths: - trunk/harbour/contrib/hbqt/THbpQtUI.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbide startup error...
Diego-3 wrote: > > Hi all, I'm Diego, I work with Angel and I'm testing hbIDE. > I use ArchLinux, Ubuntu and openSuSE. > I did a make clean and make install, and I get the same error. > Welcome onboard. I will see what is the problem. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/hbide-startup-error-tp4478978p4481154.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Hi! > HbQUI() will be fine. > Will change it shortly. It is very vague this name? Perhaps include the term "Loader" or "Load" will help us remember the full name of the class and what their purpose in the future ... Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
>>> BTW, I see such calls in many QT related calls in SVN: >>> qObj:pPtr := 0 >>> qObj:pPtr := NIL >>> >>> These can be optimized simply to: >>> qObj:pPtr := NIL >>> >> I used this method to release object instantly. >> This approach I took was since begining. My be my experiments >> at that point with Qt were showing that until I set the :pPtr to some other >> value ( not NIL ) only then I could see object relaesed. >> NIL was delaying them for some later time, may be due to GC nature. >> So I continued with it. > > For me it sounds like some hacks are implemented in HBQT to accept numeric > values instead of pointers, thus leading numeric 0 value have different > behaviour than NIL value. I reckon this could only be true if :pPtr would not be simple DATA but some SETGET method. But it's DATA (declared in hbqt_misc.prg). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Request for inet thing
Hello ppl of Harbour; I don't follow regurarly the ML, but, in an "ego surfing" session, I found this message from April White from last october: Hello Giancarlo, I'm working on the hbdoc2 program and I saw that the INET documentation is in the harbour/doc folder not harbour/doc/en-en folder. Additionally I've found that there are other functions in hbinet.c not listed in the text file. With your permission, I would like to: - make a (new) harbour/doc/en-en/hbinet.txt file using the text from your inet.txt - add a copyright entry for you - add missing functions to this file, adding parameters and return values as I can get from hbinet.c - remove the use of "xHarbour", leaving the sentance(s) as "the program" April Sure thing lad, permission granted, and sorry for the late reply. However, a search on the web for my name leads directly to my site, where you can then mail directly to me. Bests, Giancarlo Niccolai. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
>> Yes, these are shown because of the hbmk2 C++ stub, >> before the addition of it, basically no tests were >> accurate since the allocation functions were never >> overridden. >> > > To streamline what is happening behind the curtain, can > you show me a way how hbMK2 can be directed not to use > c++ stub itself but under project control. I want to put some > debug info here and there. Yes, it's documented option of hbmk2: -nohbcppmm You can even customize the stub, dump it with -debugstub option, modify it and link it to the project while using above function. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbide startup error...
Hi all, I'm Diego, I work with Angel and I'm testing hbIDE. I use ArchLinux, Ubuntu and openSuSE. I did a make clean and make install, and I get the same error. Rgds. Diego. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
>> Yes, these are shown because of the hbmk2 C++ stub, >> before the addition of it, basically no tests were >> accurate since the allocation functions were never >> overridden. >> > > It may also imply that Qt is taking two approaches, > for alloc the standard C++ way and for releases some > proprietory method not directing to our stub call. > > Again I may be utterly wrong. It would be a quite stupid thing on their part. What's theoretically possible is that we're not overriding some delete operators. Though I took the C++ allocation override information right from the QT documentation available on the web, but it's possible it's outdated. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
Hi, BTW, I see such calls in many QT related calls in SVN: qObj:pPtr := 0 qObj:pPtr := NIL These can be optimized simply to: qObj:pPtr := NIL I used this method to release object instantly. This approach I took was since begining. My be my experiments at that point with Qt were showing that until I set the :pPtr to some other value ( not NIL ) only then I could see object relaesed. NIL was delaying them for some later time, may be due to GC nature. So I continued with it. For me it sounds like some hacks are implemented in HBQT to accept numeric values instead of pointers, thus leading numeric 0 value have different behaviour than NIL value. If value of qObj:nPtr is GC pointer, both qObj:pPtr := 0 and qObj:pPtr := NIL will release it (no need to do it twice). Or we have a serious bug in GC, but I guess we do not have one. If you have a situation when double clear is required, please, try to isolate the error and reproduce it in a small self-contained sample. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: FM Stats - A puzzle I am unable to resolve
Przemysław Czerpak wrote: > > There is not differnce for GC id you make >x := 1 >x := NIL > or >x := NIL > or >x := 1 >x := NIL >x := .F. > or >... > in all cases only the 1-st assignment is significant. > Thank you for explanation. I will clean the code accordingly. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/FM-Stats-A-puzzle-I-am-unable-to-resolve-tp4477813p4480858.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: FM Stats - A puzzle I am unable to resolve
Viktor Szakáts wrote: > > Yes, these are shown because of the hbmk2 C++ stub, > before the addition of it, basically no tests were > accurate since the allocation functions were never > overridden. > To streamline what is happening behind the curtain, can you show me a way how hbMK2 can be directed not to use c++ stub itself but under project control. I want to put some debug info here and there. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/FM-Stats-A-puzzle-I-am-unable-to-resolve-tp4477813p4480847.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: FM Stats - A puzzle I am unable to resolve
Viktor Szakáts wrote: > > Yes, these are shown because of the hbmk2 C++ stub, > before the addition of it, basically no tests were > accurate since the allocation functions were never > overridden. > It may also imply that Qt is taking two approaches, for alloc the standard C++ way and for releases some proprietory method not directing to our stub call. Again I may be utterly wrong. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/FM-Stats-A-puzzle-I-am-unable-to-resolve-tp4477813p4480832.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
On Fri, 29 Jan 2010, Szak�ts Viktor wrote: > >> This class deals with loading UI object descriptions from > >> disk and creates them in memory by making one QT call. So > >> it's almost unlikely that these objects are created using > >> HBQT GC allocator functions, but rather raw C++ memory > >> allocations calls. > >> BTW, I see such calls in many QT related calls in SVN: > >> qObj:pPtr := 0 > >> qObj:pPtr := NIL > >> > >> These can be optimized simply to: > >> qObj:pPtr := NIL > > I used this method to release object instantly. > > This approach I took was since begining. My be my experiments > > at that point with Qt were showing that until I set the :pPtr to > > some other value ( not NIL ) only then I could see object relaesed. > > NIL was delaying them for some later time, may be due to GC nature. > > So I continued with it. > > I may be wrong, if yes, I will clean-up above code. > > It is always a pain to free it in two calls. > If you were right, we'd have serious problems in > our GC core collector, not just in HBQT but in any > .prg level apps using the same method (quite some). > I'd be very surprised though if we had such basic > problem in core. > If you don't believe me, it's best if you ask Przemek > for the final verdict. There is not differnce for GC id you make x := 1 x := NIL or x := NIL or x := 1 x := NIL x := .F. or ... in all cases only the 1-st assignment is significant. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
>> This class deals with loading UI object descriptions from >> disk and creates them in memory by making one QT call. So >> it's almost unlikely that these objects are created using >> HBQT GC allocator functions, but rather raw C++ memory >> allocations calls. >> >> BTW, I see such calls in many QT related calls in SVN: >> qObj:pPtr := 0 >> qObj:pPtr := NIL >> >> These can be optimized simply to: >> qObj:pPtr := NIL >> > > I used this method to release object instantly. > This approach I took was since begining. My be my experiments > at that point with Qt were showing that until I set the :pPtr to > some other value ( not NIL ) only then I could see object relaesed. > NIL was delaying them for some later time, may be due to GC nature. > So I continued with it. > > I may be wrong, if yes, I will clean-up above code. > It is always a pain to free it in two calls. If you were right, we'd have serious problems in our GC core collector, not just in HBQT but in any .prg level apps using the same method (quite some). I'd be very surprised though if we had such basic problem in core. If you don't believe me, it's best if you ask Przemek for the final verdict. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
On Fri, 29 Jan 2010, Pritpal Bedi wrote: Hi, > As I remember few weeks before /hbXBP/tests/demoxbp.exe > was showing a clean log, and now it shows up with huge list of > unreleased blocks. What I presume that after c++ stub introduced, > it actually showed up real problem in Qt which we are struggling so far. Yes it is. Now also memory allocated by NEW operator is recorded by FM stat so all objects created with NEW and never DELETEd are reported as unreleased memory blocks. Before that modification they were reported only by external programs like valgrind. Few times valgrind logs were send to this list and they contain visually similar list of unreleased blocks. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve
>> So sth bound with this object was not released. Maybe some of its >> components >> needs explicit release call. I can only guess. >> > > Exactly. But what ? I am struggling to find out. > > As I remember few weeks before /hbXBP/tests/demoxbp.exe > was showing a clean log, and now it shows up with huge list of > unreleased blocks. What I presume that after c++ stub introduced, > it actually showed up real problem in Qt which we are struggling so far. > > Any other input leading to solve this myth will be useful. Yes, these are shown because of the hbmk2 C++ stub, before the addition of it, basically no tests were accurate since the allocation functions were never overridden. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: FM Stats - A puzzle I am unable to resolve
Viktor Szakáts wrote: > >> So sth bound with this object was not released. Maybe some of its >> components >> needs explicit release call. I can only guess. > > This class deals with loading UI object descriptions from > disk and creates them in memory by making one QT call. So > it's almost unlikely that these objects are created using > HBQT GC allocator functions, but rather raw C++ memory > allocations calls. > > BTW, I see such calls in many QT related calls in SVN: > qObj:pPtr := 0 > qObj:pPtr := NIL > > These can be optimized simply to: > qObj:pPtr := NIL > I used this method to release object instantly. This approach I took was since begining. My be my experiments at that point with Qt were showing that until I set the :pPtr to some other value ( not NIL ) only then I could see object relaesed. NIL was delaying them for some later time, may be due to GC nature. So I continued with it. I may be wrong, if yes, I will clean-up above code. It is always a pain to free it in two calls. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/FM-Stats-A-puzzle-I-am-unable-to-resolve-tp4477813p4480718.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: FM Stats - A puzzle I am unable to resolve
Przemysław Czerpak wrote:
>
> The above log does not mean that QT_QUILOADER_LOAD() was called more then
> once. It only means that inside this function or some deeper functions
> called from it few memory blocks were allocated and never released.
>
Perfect explanation.
Now I know that any reserved memory blocks within a function call
are reported as many times in fm log. Because QT_QUILOADER_LOAD()
function issues only a single call to Qt's librray as such:
/*
* QWidget * load ( QIODevice * device, QWidget * parentWidget = 0 )
*/
HB_FUNC( QT_QUILOADER_LOAD )
{
hb_retptrGC( hbqt_gcAllocate_QWidget( hbqt_par_QUiLoader( 1 )->load(
hbqt_par_QIODevice( 2 ), hbqt_par_QWidget( 3 ) ), false ) );
}
so my understanding is that Qt is directing mem alloc/release call to c++
stub
injected by hbMK2. Is this right ? Otherwise how fm stats could record how
many
blocks are allocated.
>> But the fm stats show otherwise - 14 for FindReplace dialog.
>
> No it does not show anything like that. It only shows that more then one
> memory block was allocated by this function but you do not have any
> information about number of QT_QUILOADER_LOAD() calls.
>
No, I have information about how many calls to QT_QUILOADER_LOAD() - 1.
>> Also I am receiving in this log, all the objects created with new()
>> which are got freed ( I can visualize ) before RETURN is reached in
>> main().
>
> So sth bound with this object was not released. Maybe some of its
> components
> needs explicit release call. I can only guess.
>
Exactly. But what ? I am struggling to find out.
As I remember few weeks before /hbXBP/tests/demoxbp.exe
was showing a clean log, and now it shows up with huge list of
unreleased blocks. What I presume that after c++ stub introduced,
it actually showed up real problem in Qt which we are struggling so far.
Any other input leading to solve this myth will be useful.
-
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/FM-Stats-A-puzzle-I-am-unable-to-resolve-tp4477813p4480679.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Thanks a lot. Brgds, Viktor On 2010 Jan 29, at 16:35, Pritpal Bedi wrote: > > > Viktor Szakáts wrote: >> >> Just one comment: The name of the class should be HBQUILOADER() >> (or HBQUI()) to be in sync with rest of classes. HBP*() namespace >> is reserved for HBXBP lib. >> > > HbQUI() will be fine. > Will change it shortly. > > > > > - > enjoy hbIDEing... >Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/SF-net-SVN-harbour-project-13731-trunk-harbour-tp4477687p4480564.html > Sent from the harbour-devel mailing list archive at Nabble.com. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: SF.net SVN: harbour-project:[13731] trunk/harbour
Viktor Szakáts wrote: > > Just one comment: The name of the class should be HBQUILOADER() > (or HBQUI()) to be in sync with rest of classes. HBP*() namespace > is reserved for HBXBP lib. > HbQUI() will be fine. Will change it shortly. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13731-trunk-harbour-tp4477687p4480564.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbide startup error...
marco bra wrote: > > Ubuntu 9.10 32bits hbide - svn rev. 13731 compiled with -rebuild parameter > > At start of hbide before any hbide graphics appear to me i get a dialog > error window that show: > > Error BASE/1004 No exported method: SETMOUSETRACKING > > Called from SETMOUSETRACKING(0) > > Called from HBPQTUI:SETMOUSETRACKING(0) > > Called from XBPDIALOG:CREATE(0) > > Called from IDEDOCKS:BUILDDIALOG(134) > > Called from HBIDE:CREATE(282) > > Called from MAIN(100) > Did you compiled hbQT, hbXBP also? If not build them clean. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis_&_design_ -- View this message in context: http://n2.nabble.com/hbide-startup-error-tp4478978p4480542.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FM Stats - A puzzle I am unable to resolve
> The above log does not mean that QT_QUILOADER_LOAD() was called more then > once. It only means that inside this function or some deeper functions > called from it few memory blocks were allocated and never released. > >> But the fm stats show otherwise - 14 for FindReplace dialog. > > No it does not show anything like that. It only shows that more then one > memory block was allocated by this function but you do not have any > information about number of QT_QUILOADER_LOAD() calls. > >> Also I am receiving in this log, all the objects created with new() >> which are got freed ( I can visualize ) before RETURN is reached in main(). > > So sth bound with this object was not released. Maybe some of its components > needs explicit release call. I can only guess. This class deals with loading UI object descriptions from disk and creates them in memory by making one QT call. So it's almost unlikely that these objects are created using HBQT GC allocator functions, but rather raw C++ memory allocations calls. BTW, I see such calls in many QT related calls in SVN: qObj:pPtr := 0 qObj:pPtr := NIL These can be optimized simply to: qObj:pPtr := NIL Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13731] trunk/harbour
Thank you. Just one comment: The name of the class should be HBQUILOADER() (or HBQUI()) to be in sync with rest of classes. HBP*() namespace is reserved for HBXBP lib. Brgds, Viktor On 2010 Jan 29, at 03:07, vouch...@users.sourceforge.net wrote: > Revision: 13731 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13731&view=rev > Author: vouchcac > Date: 2010-01-29 02:07:36 + (Fri, 29 Jan 2010) > > Log Message: > --- > 2010-01-28 18:03 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbqt/filelist.mk > + contrib/hbqt/THbpQtUI.prg > > - contrib/hbxbp/hbpqtui.prg > * contrib/hbxbp/Makefile > * contrib/hbxbp/xbpdialog.prg > * contrib/hbxbp/xbpwindow.prg > > * contrib/hbide/hbide.prg > * contrib/hbide/idedocks.prg > * contrib/hbide/idefindreplace.prg > * contrib/hbide/ideprojmanager.prg > * contrib/hbide/idethemes.prg > >-+ Shifted HbpQtUI() class from hbXBP to hbQT. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbide/hbide.prg >trunk/harbour/contrib/hbide/idedocks.prg >trunk/harbour/contrib/hbide/idefindreplace.prg >trunk/harbour/contrib/hbide/ideprojmanager.prg >trunk/harbour/contrib/hbide/idethemes.prg >trunk/harbour/contrib/hbqt/filelist.mk >trunk/harbour/contrib/hbxbp/Makefile >trunk/harbour/contrib/hbxbp/xbpdialog.prg >trunk/harbour/contrib/hbxbp/xbpwindow.prg > > Added Paths: > --- >trunk/harbour/contrib/hbqt/THbpQtUI.prg > > Removed Paths: > - >trunk/harbour/contrib/hbxbp/hbpqtui.prg > > > This was sent by the SourceForge.net collaborative development platform, the > world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13732] trunk/harbour
Revision: 13732 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13732&view=rev Author: druzus Date: 2010-01-29 12:10:05 + (Fri, 29 Jan 2010) Log Message: --- 2010-01-29 13:09 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rdd/dbfcdx/dbfcdx1.c ! fixed possible unreleased lock after last modification in SIXCDX - many thanks to Mindaugas for the information Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rdd/dbfcdx/dbfcdx1.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13729] trunk/harbour
On Fri, 29 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
> dru...@users.sourceforge.net wrote:
> >2010-01-28 23:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
> > * harbour/src/rdd/dbfcdx/dbfcdx1.c
> >+ enabled automatic template order setting in Harbour SIXCDX RDD using
> > the same method as SIX3 SIXCDX RDD seems to use: by checking leading
> > character of key expression for: "sxChar(", "sxDate(", "sxNum(" and
> > "sxLog("
> I'm not a good index locking and dbfcdx driver internals guru, but
> new code looks like a little buggy.
> dbfcdx1.c line 8414 has
> hb_cdxIndexLockWrite( pTag->pIndex );
> but line 8437
> hb_cdxIndexUnLockWrite( pTag->pIndex );
> is protected by line 8434
> if( pKey )
> I guess if pKey == NULL index remains locked!
> The same for lines 8465 and 8496.
Yes. My fault. Thank you very much for checking it.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13729] trunk/harbour
Hi,
dru...@users.sourceforge.net wrote:
2010-01-28 23:24 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/src/rdd/dbfcdx/dbfcdx1.c
+ enabled automatic template order setting in Harbour SIXCDX RDD using
the same method as SIX3 SIXCDX RDD seems to use: by checking leading
character of key expression for: "sxChar(", "sxDate(", "sxNum(" and
"sxLog("
I'm not a good index locking and dbfcdx driver internals guru, but new
code looks like a little buggy.
dbfcdx1.c line 8414 has
hb_cdxIndexLockWrite( pTag->pIndex );
but line 8437
hb_cdxIndexUnLockWrite( pTag->pIndex );
is protected by line 8434
if( pKey )
I guess if pKey == NULL index remains locked!
The same for lines 8465 and 8496.
Regards,
Mindaugas
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbide startup error...
Ubuntu 9.10 32bits hbide - svn rev. 13731 compiled with -rebuild parameter At start of hbide before any hbide graphics appear to me i get a dialog error window that show: Error BASE/1004 No exported method: SETMOUSETRACKING Called from SETMOUSETRACKING(0) Called from HBPQTUI:SETMOUSETRACKING(0) Called from XBPDIALOG:CREATE(0) Called from IDEDOCKS:BUILDDIALOG(134) Called from HBIDE:CREATE(282) Called from MAIN(100) Thank you ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] FM Stats - A puzzle I am unable to resolve
On Thu, 28 Jan 2010, Pritpal Bedi wrote: Hi > Below is the part of hb_out.log : [...] > Block 5 0x11f1158 (size 8) QT_QUILOADER_LOAD(0), "0600C0E02701" > Block 6 0x11e1960 (size 8) QT_QUILOADER_LOAD(0), "070010E12701" > Block 7 0x124b510 (size 8) QT_QUILOADER_LOAD(0), "080048E12701" > Block 8 0x124b578 (size 8) QT_QUILOADER_LOAD(0), "090078E12701" > Block 9 0x124b5e0 (size 8) QT_QUILOADER_LOAD(0), "0A00D8E12701" [...] > I can understand the entries like >Block 4 0x1203df0 (size 4) QT_QUILOADER(0), "289A3D00" > but cannot grab why these are there as recurring : >Block 5 0x11f1158 (size 8) QT_QUILOADER_LOAD(0), "0600C0E02701" > almost the size of controls in a dialog loaded with HbpQtUI() class. > The puzzle is that QT_QUILOADER_LOAD() is called _ONCE_ only for any dialog. The above log does not mean that QT_QUILOADER_LOAD() was called more then once. It only means that inside this function or some deeper functions called from it few memory blocks were allocated and never released. > But the fm stats show otherwise - 14 for FindReplace dialog. No it does not show anything like that. It only shows that more then one memory block was allocated by this function but you do not have any information about number of QT_QUILOADER_LOAD() calls. > Also I am receiving in this log, all the objects created with new() > which are got freed ( I can visualize ) before RETURN is reached in main(). So sth bound with this object was not released. Maybe some of its components needs explicit release call. I can only guess. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBF encryption
Przemysław Czerpak wrote: If you want to change password then you have to decrypt the table and then encrypt it again with new password. Ahh! Thanks very much. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DBF encryption
On Wed, 20 Jan 2010, Alex Strickland wrote: Hi, > I was trying to understand encryption of dbf's and I wrote this test. > I didn't expect the last two lines of output (see end), but perhaps > it is invalid to expect an encrypted file to be encrypted again? If > so, shouldn't: > dbcrypt->( dbinfo( DBI_ENCRYPT, "fredflintstone" ) ) > cause an error or return false? DBI_ENCRYPT/DBI_DECRYPT encrypt/decrypt whole table but they have protection against multiple calls so they do not encrypt already encrypted table and do not decrypt already decrypted table. They return table encryption status (the same value as DBI_ISENCRYPTED). Your results confirms such behavior. If you want to change password then you have to decrypt the table and then encrypt it again with new password. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
