RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity to
continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue with
the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26347229.html
Sent from the Harbour - Dev 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
Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Why Now the repository is dead?
2009/11/14 Bisz István istvan.b...@t-online.hu:
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity to
continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue with
the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26347229.html
Sent from the Harbour - Dev 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
--
Massimo Belgrano
___
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:[12868] trunk/harbour
Try to compile something after the upgrade to the latest revision.
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. november 14. 10:12
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Why Now the repository is dead?
2009/11/14 Bisz István istvan.b...@t-online.hu:
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity
to continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue
with the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-
tp26346347p26347229.html
Sent from the Harbour - Dev 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
--
Massimo Belgrano
___
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] SF.net SVN: harbour-project:[12868] trunk/harbour
c:\harbour\contrib\hbqt\testshbmk2 demoqt
Unrecoverable error 9994: Harbour CP (NL850) initialization failure
2009/11/14 Bisz István istvan.b...@t-online.hu:
Try to compile something after the upgrade to the latest revision.
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. november 14. 10:12
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Why Now the repository is dead?
2009/11/14 Bisz István istvan.b...@t-online.hu:
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity
to continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue
with the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-
tp26346347p26347229.html
Sent from the Harbour - Dev 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
--
Massimo Belgrano
___
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
--
Massimo Belgrano
Iscritto all'albo dei CTU presso il Tribunale di Novara per materia Informatica
Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962)
Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione
___
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:[12868] trunk/harbour
Hi Pritpal,
Just reviewed the demoqt.
Could you please commit a version with the following modification:
1. hb_toOutDebug() conditioned by __debug__ or switch to:
#if defined( __HB_OUTDEBUG__ )
#if defined( __PLATFORM__WINDOWS ) .AND. defined( __HB_WINDEBUG__ )
#xtranslate HB_OUTDEBUG( [x] ) = wapi_OutputDebugString( x )
#else
#xtranslate HB_OUTDEBUG( [x] ) = hb_TraceString( x )
#endif
#else
#xtranslate HB_OUTDEBUG( [x] ) = iif( .T.,, )
#endif
mentioned by Viktor.
2. The sequence:
CASE cType == WebPage
oDlg := QWebView():new()
oUrl := QUrl():new()
oUrl:setUrl( http://www.harbour.vouch.info; )
QT_QWebView_SetUrl( QT_PTROF( oDlg ), QT_PTROF( oUrl ) )
oDlg:setWindowTitle( Harbour-QT Web Page Navigator )
oDlg:exec()
should be replaced with a not implemented! message until fixing this issue.
These two things will make it, hopefully, error free on different platforms.
Thank you and best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 9:56
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity to
continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue with
the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26347229.html
Sent from the Harbour - Dev 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 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:[12868] trunk/harbour
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
Yes.
And crash at what point? On exit ? If yes, then it is possibly that
Yes.
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
Also, integrated web browse didn't work, I forget to
mention that, but that's another issue.
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:[12868] trunk/harbour
I have no idea for a fix, I simply used cpinfo.prg to
generate this CP without ever touching the source.
Maybe it needs HB_CP_RAW to be enabled manually?
Brgds,
Viktor
On 2009 Nov 14, at 10:19, Bisz István wrote:
Try to compile something after the upgrade to the latest revision.
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. november 14. 10:12
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Why Now the repository is dead?
2009/11/14 Bisz István istvan.b...@t-online.hu:
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity
to continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue
with the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-
tp26346347p26347229.html
Sent from the Harbour - Dev 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
--
Massimo Belgrano
___
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 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:[12868] trunk/harbour
Could you please revert to a stabile status, until a fix is ready?
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2009. november 14. 12:01
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
I have no idea for a fix, I simply used cpinfo.prg to
generate this CP without ever touching the source.
Maybe it needs HB_CP_RAW to be enabled manually?
Brgds,
Viktor
On 2009 Nov 14, at 10:19, Bisz István wrote:
Try to compile something after the upgrade to the latest revision.
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Massimo Belgrano
Sent: 2009. november 14. 10:12
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Why Now the repository is dead?
2009/11/14 Bisz István istvan.b...@t-online.hu:
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle
the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity
to continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue
with the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-
tp26346347p26347229.html
Sent from the Harbour - Dev 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
--
Massimo Belgrano
___
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 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] SF.net SVN: harbour-project:[12868] trunk/harbour
Could you please revert to a stabile status, until a fix is ready? I'd rather wait for a proper fix. Until then, the offending file can be deleted from Makefile locally. 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:[12868] trunk/harbour
It's ok now, as I am short in time. Thank you. -Original Message- From: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts Sent: 2009. november 14. 12:28 To: Harbour Project Main Developer List. Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour Could you please revert to a stabile status, until a fix is ready? I'd rather wait for a proper fix. Until then, the offending file can be deleted from Makefile locally. Brgds, Viktor ___ 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] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
See my findings: to activate the tracing of the actual demoqt on Windows+mingw
I tried to:
1. compile hbqt with:
@set HB_USER_CFLAGS=-D__debug__
@set HB_USER_PRGFLAGS=-D__debug__
2. build
hbmk2 demoqt -lxhb -lpsapi
After these steps I have got a running exe, but I can't see any traces on my
Vista.
Any advice is useful, thanks.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 11:04
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Just reviewed the demoqt.
Could you please commit a version with the following modification:
1. hb_toOutDebug() conditioned by __debug__ or switch to:
#if defined( __HB_OUTDEBUG__ )
#if defined( __PLATFORM__WINDOWS ) .AND. defined( __HB_WINDEBUG__ )
#xtranslate HB_OUTDEBUG( [x] ) = wapi_OutputDebugString( x )
#else
#xtranslate HB_OUTDEBUG( [x] ) = hb_TraceString( x )
#endif
#else
#xtranslate HB_OUTDEBUG( [x] ) = iif( .T.,, )
#endif
mentioned by Viktor.
2. The sequence:
CASE cType == WebPage
oDlg := QWebView():new()
oUrl := QUrl():new()
oUrl:setUrl( http://www.harbour.vouch.info; )
QT_QWebView_SetUrl( QT_PTROF( oDlg ), QT_PTROF( oUrl ) )
oDlg:setWindowTitle( Harbour-QT Web Page Navigator )
oDlg:exec()
should be replaced with a not implemented! message until fixing this issue.
These two things will make it, hopefully, error free on different platforms.
Thank you and best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 9:56
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity to
continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue with
the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes, but I enabled it
because, otherwise, hb_out.log was containing a long list of
unfreed memory blocks.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26347229.html
Sent from the Harbour - Dev 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 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] SF.net SVN: harbour-project:[12868] trunk/harbour
On Sat, 14 Nov 2009, Szak�ts Viktor wrote: Hi, I have no idea for a fix, I simply used cpinfo.prg to generate this CP without ever touching the source. Maybe it needs HB_CP_RAW to be enabled manually? Exactly. It's a classic example which cannot be correctly encoded in human readable form. The problem is caused by the fact that in NL850 upper and lower letters are sorted in different order. ÿ is sorted before j but upper( ÿ ) gives Y which is sorted just before Z so this CP has to be converted to binary form. I'll check if I can easy update cpinfo.prg to detect such situations automatically. BTW I will have to update existing CDP code to work well with CPs where CHR(0) is not sorted as 1-st character - the MDX sorting tables needs it. best regards, Przemek ___ 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:[12873] trunk/harbour
Revision: 12873 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12873view=rev Author: vszakats Date: 2009-11-14 15:16:35 + (Sat, 14 Nov 2009) Log Message: --- 2009-11-14 16:15 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * external/sqlite3/sqlite3.c * external/sqlite3/sqlite3.h + sqlite upgraded to 3.6.20 (from 3.6.18) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/external/sqlite3/sqlite3.c trunk/harbour/external/sqlite3/sqlite3.h 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] Testing Linux
On 13/11/09 15:03, Mario H. Sabado wrote: Hi Guy, Message: 9 Date: Fri, 13 Nov 2009 08:06:07 +0100 From: Guy Roussinguy.rous...@teledetection.fr Subject: Re: [Harbour] Testing Linux To: Harbour Project Main Developer List. harbour@harbour-project.org Message-ID:4afd055f.40...@teledetection.fr Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I have tried building Harbour under Mandriva 2010 and compiled the hello.prg successfully but when I run, I have the following error. But I have verified that the libharbour.so was found under /usr/local/lib and /usr/local/lib/harbour. Add as root: /usr/local/lib/ /usr/local/lib/harbour in /etc/ld.so.conf then type: ldconfig Guy That did it! Thank you for the help. Best regards, Mario ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Mario, see also :- https://sourceforge.net/apps/phpbb/harbour-project/viewtopic.php?p=77#p77 ___ 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:[12874] trunk/harbour
Revision: 12874 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12874view=rev Author: vszakats Date: 2009-11-14 17:11:06 + (Sat, 14 Nov 2009) Log Message: --- 2009-11-14 18:08 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/hbi18n1.c + Added plural form support for these languages: CS, FR, GA, HR, HU, JA, KO, LV, PT-BR, RO, SK, SL, SR, TR, UK, VI * src/rtl/cputime.c * Minor formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/rtl/cputime.c trunk/harbour/src/rtl/hbi18n1.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] SF.net SVN: harbour-project:[12875] trunk/harbour
Revision: 12875 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12875view=rev Author: vouchcac Date: 2009-11-14 18:09:17 + (Sat, 14 Nov 2009) Log Message: --- 2009-11-14 10:07 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/gtwvg/wvtwin.ch + Added few more constants. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/wvtwin.ch 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:[12868] trunk/harbour
Hi Pritpal,
Please consult demoqt test on Fedora12 listed below:
[ist...@localhost tests]$ hbmk2 demoqt -lxhb
hbmk2: Processing local make script: hbmk.hbm
hbmk2: Processing configuration: /usr/local/bin/hbmk.cfg
Harbour 2.0.0beta3 (Rev. 12874)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoqt.prg'...
Lines 1032, Functions/Procedures 22
Generating C source output to 'demoqt.c'... Done.
[ist...@localhost tests]$ ./demoqt
unknown: Fatal IO error 2 (No such file or directory) on X server :0.0.
X Error: BadIDChoice (invalid resource ID chosen for this connection) 14
Major opcode: 1 (X_CreateWindow)
Resource id: 0x442
X Error: BadIDChoice (invalid resource ID chosen for this connection) 14
Extension:148 (RENDER)
Minor opcode: 4 (RenderCreatePicture)
Resource id: 0x443
X Error: BadIDChoice (invalid resource ID chosen for this connection) 14
Major opcode: 1 (X_CreateWindow)
Resource id: 0x444
unknown: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
The application 'unknown' lost its connection to the display :0.0;
most likely the X server was shut down or you killed/destroyed
the application.
the error was fixed by the commenting out the 'hb_toOutDebug()' calls.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 13:08
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
See my findings: to activate the tracing of the actual demoqt on Windows+mingw
I tried to:
1. compile hbqt with:
@set HB_USER_CFLAGS=-D__debug__
@set HB_USER_PRGFLAGS=-D__debug__
2. build
hbmk2 demoqt -lxhb -lpsapi
After these steps I have got a running exe, but I can't see any traces on my
Vista.
Any advice is useful, thanks.
Best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 11:04
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Just reviewed the demoqt.
Could you please commit a version with the following modification:
1. hb_toOutDebug() conditioned by __debug__ or switch to:
#if defined( __HB_OUTDEBUG__ )
#if defined( __PLATFORM__WINDOWS ) .AND. defined( __HB_WINDEBUG__ )
#xtranslate HB_OUTDEBUG( [x] ) = wapi_OutputDebugString( x )
#else
#xtranslate HB_OUTDEBUG( [x] ) = hb_TraceString( x )
#endif
#else
#xtranslate HB_OUTDEBUG( [x] ) = iif( .T.,, )
#endif
mentioned by Viktor.
2. The sequence:
CASE cType == WebPage
oDlg := QWebView():new()
oUrl := QUrl():new()
oUrl:setUrl( http://www.harbour.vouch.info; )
QT_QWebView_SetUrl( QT_PTROF( oDlg ), QT_PTROF( oUrl ) )
oDlg:setWindowTitle( Harbour-QT Web Page Navigator )
oDlg:exec()
should be replaced with a not implemented! message until fixing this issue.
These two things will make it, hopefully, error free on different platforms.
Thank you and best regards,
István
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Bisz István
Sent: 2009. november 14. 9:56
To: 'Harbour Project Main Developer List.'
Subject: RE: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal,
Thank you for the new QPointer handling integration, now we can handle the
QObjects deleted by Qt in his parent-child mechanism. There is a necessity to
continue with the HB-Qt interface analysis, concentrating on the:
void * hbqt_gcpointer( int iParam )
{
QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( gcFuncs(), iParam );
if( p p-ph )
{
return p-ph;
}
else
{
return hb_parptr( iParam );
}
}
function enhancements, to signal at harbour level the already deleted Qt
objects access tentative.
Now the repository is dead, due to the CP modifications, I will continue with
the tests later.
Best regards,
István (my first name)
-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. november 14. 5:57
To: harbour@harbour-project.org
Subject: Re: [Harbour] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
NOTE: Bisz István had disabled it to avoid crashes,
[Harbour] SF.net SVN: harbour-project:[12876] trunk/harbour
Revision: 12876 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12876view=rev Author: vouchcac Date: 2009-11-14 20:18:09 + (Sat, 14 Nov 2009) Log Message: --- 2009-11-14 12:16 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/tests/demoqt.prg ! Fixed to excluse non-working components and streamlined hb_toOutDebug(). Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/tests/demoqt.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:[12868] trunk/harbour
Hello Istvan Bisz István wrote: See my findings: to activate the tracing of the actual demoqt on Windows+mingw I tried to: 1. compile hbqt with: @set HB_USER_CFLAGS=-D__debug__ @set HB_USER_PRGFLAGS=-D__debug__ 2. build hbmk2 demoqt -lxhb -lpsapi After these steps I have got a running exe, but I can't see any traces on my Vista. Any advice is useful, thanks. You need a windows debugger for this purpose. I use dbgview.exe which you can find on the net. Or tell me where should I send it to you. BTW can you strip the messages to which you are replying? Just keep relevant portion only into your message. Sometimes it becomes difficult to locate the excat message of your current reply. If you are ready with Harbour standard coding we can ask Viktor to grant your write access on SVN. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26353560.html Sent from the Harbour - Dev 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] SF.net SVN: harbour-project:[12868] trunk/harbour
Hi Pritpal, Thanks. You need a windows debugger for this purpose. I use dbgview.exe which you can find on the net. Or tell me where should I send it to you. I will try to download it. BTW can you strip the messages to which you are replying? Just keep relevant portion only into your message. Sometimes it becomes difficult to locate the excat message of your current reply. OK. I always forget it with this list, as my Outlook works in a different way, requested by others. If you are ready with Harbour standard coding we can ask Viktor to grant your write access on SVN. Maybe I need here an input from your side, in any case thanks for your trustfulness. Best regards, István ___ 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:[12868] trunk/harbour
What is the reason debug calls need to be re-invented every time? We have working solution in xbp.ch, and now there is _again_ a new one developed in hbqt with different function names, different enabler logic and different logging logic (which again breaks all non-Windows). Pls change to this one in hbqt, too: --- #if defined( __HB_OUTDEBUG__ ) #if defined( __PLATFORM__WINDOWS ) .AND. defined( __HB_WINDEBUG__ ) #xtranslate HB_OUTDEBUG( [x] ) = wapi_OutputDebugString( x ) #else #xtranslate HB_OUTDEBUG( [x] ) = hb_TraceString( x ) #endif #else #xtranslate HB_OUTDEBUG( [x] ) = iif( .T.,, ) #endif --- Possibly also __debug__ invocation on C level should be changed to __HB_OUTDEBUG__ to have one less variation for the same thing. Brgds, Viktor On 2009 Nov 14, at 21:22, Pritpal Bedi wrote: Hello Istvan Bisz István wrote: See my findings: to activate the tracing of the actual demoqt on Windows+mingw I tried to: 1. compile hbqt with: @set HB_USER_CFLAGS=-D__debug__ @set HB_USER_PRGFLAGS=-D__debug__ 2. build hbmk2 demoqt -lxhb -lpsapi After these steps I have got a running exe, but I can't see any traces on my Vista. Any advice is useful, thanks. You need a windows debugger for this purpose. I use dbgview.exe which you can find on the net. Or tell me where should I send it to you. BTW can you strip the messages to which you are replying? Just keep relevant portion only into your message. Sometimes it becomes difficult to locate the excat message of your current reply. If you are ready with Harbour standard coding we can ask Viktor to grant your write access on SVN. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12868--trunk-harbour-tp26346347p26353560.html Sent from the Harbour - Dev 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:[12877] trunk/harbour
Revision: 12877 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12877view=rev Author: vszakats Date: 2009-11-14 22:17:07 + (Sat, 14 Nov 2009) Log Message: --- 2009-11-14 23:16 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt.ch * contrib/hbqt/tests/demoqt.prg + Changed to use same .prg level debug trace call method as in hbxbp. Enable it with __HB_OUTDEBUG__. On Windows to use OutputDebugString() instead of regular Harbour trace calls, also #define __HB_WINDEBUG__. In this case, also link hbwin lib (not xhb lib). * Moved QT_PTROF() macro from demo code to header. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.ch trunk/harbour/contrib/hbqt/tests/demoqt.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] Does anybody have a mercurial repository ?
I use Mercurial as my versioning tool... I'm trying to convert trunk from svn to hg but it seems to last forever... Is a mercurial repository available ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Does anybody have a mercurial repository ?
On 2009 Nov 15, at 00:22, francesco perillo wrote: I use Mercurial as my versioning tool... I'm trying to convert trunk from svn to hg but it seems to last forever... Is a mercurial repository available ? No. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] FYI: beta3 release files moved to sf.net
as subject. this way it moves our download stats and it moves away load from my webspace provider. '-20090905' postfix has been removed from filenames in the process. Webalizer stats to date: Nov HitskB File 41 1179202 harbour-2.0.0beta3-win-20090905.exe 15 282730 harbour-2.0.0beta3-win-20090905.7z 23 108863 harbour-2.0.0beta3-src-20090905.zip Oct HitskB File 221 1494402 harbour-2.0.0beta3-win-20090905.exe 67 521257 harbour-2.0.0beta3-win-20090905.7z 23 133706 harbour-2.0.0beta3-src-20090905.zip Sep HitskB File 288 2632633 harbour-2.0.0beta3-win-20090905.exe 254 1809235 harbour-2.0.0beta3-win-20090905.7z 81 467573 harbour-2.0.0beta3-src-20090905.zip Hits is obviously off for some (to me) unknown reason. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Bug in compiling trunk with bcc
I had to rem this line in config\win\global.mk to compile succesfully in bcc 5.5 # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32 bcc has no kernel32.lib and the other ones I know that I should not use bcc (features and speed) but it's listed as supported... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in compiling trunk with bcc
Viktor, you are right as usual On Sun, Nov 15, 2009 at 1:25 AM, Viktor Szakáts harbour...@syenar.hu wrote: I had to rem this line in config\win\global.mk to compile succesfully in bcc 5.5 # SYSLIBS += kernel32 user32 ws2_32 advapi32 gdi32 bcc has no kernel32.lib and the other ones This is not true. All of them are present in PSDK dir, which is part of BCC 5.5 kit. Yes there are. If it doesn't work for you pls post your env and error, Error: bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -onortl.obj -c ../../../nortl. c ../../../nortl.c: tlib.exe /P128 ..\..\..\..\..\lib\win\bcc\hbnortl.lib -+nortl.obj TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation Warning: 'nortl' not found in library bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -ohbpp.obj -c ../../../hbpp.c ../../../hbpp.c: bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -ohbpp_dyn.obj -DHB_DYNLIB -c ../../../hbpp.c ../../../hbpp.c: bcc32.exe -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -L../../../../../lib/win/bcc -e..\..\..\..\..\bin\win\bcc\h bpp.exe hbpp.obj ../../../../../lib/win/bcc/hbnortl.lib ../../../../../lib/win/bcc/hbcommon.lib kernel32.lib user32.lib ws2_32.lib advapi32.lib gdi32.lib Fatal: Unable to open file 'KERNEL32.LIB' win-make[3]: *** [hbpp.exe] Error 1 rm hbpp.obj win-make[2]: *** [descend] Error 2 win-make[1]: *** [pp] Error 2 win-make: *** [src] Error 2 As you can see, kernel32 is listed and since my bcc32.cfg is -Ic:\dev\l\bcc55\include -Lc:\dev\l\bcc55\lib it's not found I now added -L...\psdk and works I'm only a bit puzzled about the fact that removing that libraries it compiles, links and works. Thanks, Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in compiling trunk with bcc
On Sun, 15 Nov 2009, francesco perillo wrote: Hi, I'm only a bit puzzled about the fact that removing that libraries it compiles, links and works. Amazing, do you know that I can compile and link my application without xhb.lib and final binaries works. Does it means that we should say that it's a bug in Harbour SVN and suggest to remove 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] Bug in compiling trunk with bcc
If it doesn't work for you pls post your env and error, Error: bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -onortl.obj -c ../../../nortl. c ../../../nortl.c: tlib.exe /P128 ..\..\..\..\..\lib\win\bcc\hbnortl.lib -+nortl.obj TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation Warning: 'nortl' not found in library bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -ohbpp.obj -c ../../../hbpp.c ../../../hbpp.c: bcc32.exe -I. -I../../../../../include -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -ohbpp_dyn.obj -DHB_DYNLIB -c ../../../hbpp.c ../../../hbpp.c: bcc32.exe -q -tWM -w -w-sig- -Q -d -6 -O2 -OS -Ov -Oi -Oc -L../../../../../lib/win/bcc -e..\..\..\..\..\bin\win\bcc\h bpp.exe hbpp.obj ../../../../../lib/win/bcc/hbnortl.lib ../../../../../lib/win/bcc/hbcommon.lib kernel32.lib user32.lib ws2_32.lib advapi32.lib gdi32.lib Fatal: Unable to open file 'KERNEL32.LIB' win-make[3]: *** [hbpp.exe] Error 1 rm hbpp.obj win-make[2]: *** [descend] Error 2 win-make[1]: *** [pp] Error 2 win-make: *** [src] Error 2 As you can see, kernel32 is listed and since my bcc32.cfg is -Ic:\dev\l\bcc55\include -Lc:\dev\l\bcc55\lib it's not found I now added -L...\psdk and works Yes, this is the key. Upgrade to latest SVN and PSDK dir is added automatically by the build process. I'm only a bit puzzled about the fact that removing that libraries it compiles, links and works. These libs are added internally by BCC even if you don't add them explicitly. We're adding them explicitly as we're using a std set of system libs for all Windows compilers. 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:[12868] trunk/harbour
On Fri, 13 Nov 2009, Pritpal Bedi wrote:
Hi
Viktor Szakáts wrote:
Now I'm getting crash on exit using MinGW + Win7.
demoxbp.exe ?
And crash at what point? On exit ? If yes, then it is possibly that
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block );
destroy();
}
needs some overhaul. What I think is that - hb_itemRelease( block ); -
has to be guarded in someway, but what, I am unable to figure out.
Przemek can shed light on this aspect.
I think that it's enough if you look at this code more carefully ;-)
This valgrind log should help you.
==8925== Invalid read of size 8
==8925==at 0x75D5930: hb_xRefDec (fm.c:840)
==8925==by 0x75D75F5: hb_gcRefFree (garbage.c:313)
==8925==by 0x75D76FF: hb_itemRelease (itemapi.c:174)
==8925==by 0x4568F0: HbDbfModel::~HbDbfModel() (hbqt_slots.cpp:2475)
==8925==by 0x7605406: hb_vmProc (hvm.c:5732)
==8925==by 0x75E19C1: hb_vmExecute (hvm.c:1619)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x75E1DA9: hb_vmExecute (hvm.c:1651)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x75E1DA9: hb_vmExecute (hvm.c:1651)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x7604100: hb_arrayEval (arrays.c:1329)
==8925==by 0x75CE70F: HB_FUN_AEVAL (arrayshb.c:372)
==8925==by 0x7605406: hb_vmProc (hvm.c:5732)
==8925==by 0x75E19C1: hb_vmExecute (hvm.c:1619)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925== Address 0xc18e500 is 0 bytes inside a block of size 72 free'd
==8925==at 0x4C23DD8: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8925==by 0x75D76FF: hb_itemRelease (itemapi.c:174)
==8925==by 0x4568E7: HbDbfModel::~HbDbfModel() (hbqt_slots.cpp:2292)
==8925==by 0x7605406: hb_vmProc (hvm.c:5732)
==8925==by 0x75E19C1: hb_vmExecute (hvm.c:1619)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x75E1DA9: hb_vmExecute (hvm.c:1651)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x75E1DA9: hb_vmExecute (hvm.c:1651)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x7604100: hb_arrayEval (arrays.c:1329)
==8925==by 0x75CE70F: HB_FUN_AEVAL (arrayshb.c:372)
==8925==by 0x7605406: hb_vmProc (hvm.c:5732)
==8925==by 0x75E19C1: hb_vmExecute (hvm.c:1619)
==8925==by 0x75E414A: hb_vmSend (hvm.c:5880)
==8925==by 0x75E1DA9: hb_vmExecute (hvm.c:1651)
HbDbfModel::~HbDbfModel( void )
{
hb_itemRelease( block ); // hbqt_slots.cpp:2292
destroy();
}
void HbDbfModel::destroy()
{
hb_itemRelease( block ); // hbqt_slots.cpp:2475
}
As you can see this code calls explicitly hb_itemRelease( block ) twice
and it causes memory corruption.
best regards,
Przemek
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] OLE objects syntax...
I have an OLE object (PdfCreator, a pdf printer driver for windows) that among other methods has the followings: Public Property Get cOption(ByVal PropertyName As String) As Variant Public Property Let cOption(ByVal PropertyName As String, ByVal Value As Variant) Public Property Get cVisible() As Boolean Public Property Let cVisible(ByVal Value As Boolean) My xHarbour code was: object:cVisible( .T.) and in Harbour object:cVisible := .T. In Harbour I can: ? object:cOption(property) and have the correct value but I don't know how to set that value ! object:cOption(property) := .T. is not accepted by the compiler, object:cOption(property, .T.) is a run-time error Is there another way to set this value ? It may also be a problem of the OLE object, since I oAS:Cells( 7, 1 ):Value := Timestamp: but this has the :Value part. and the compiler accepts it Thanks, Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in compiling trunk with bcc
I now added -L...\psdk and works Yes, this is the key. Upgrade to latest SVN and PSDK dir is added automatically by the build process. I'm at the tip Harbour 2.0.0beta3 (Rev. 12877) I only set HB_COMPILER=bcc (since I have a couple others installed) Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in compiling trunk with bcc
I know that this list is perhaps not the correct one I hope you will forgive me :-) Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OLE objects syntax...
Hi, In Harbour I can: ? object:cOption(property) and have the correct value but I don't know how to set that value ! Do you have any self contained sample? object:cOption(property) := .T. is not accepted by the compiler, Just like STR(7) := .T. object:cOption(property, .T.) is a run-time error What error? Is there another way to set this value ? It may also be a problem of the OLE object, since I oAS:Cells( 7, 1 ):Value := Timestamp: but this has the :Value part. and the compiler accepts it Just like any object:property := value Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Bug in compiling trunk with bcc
Upgrade to latest SVN and PSDK dir is added automatically by the build process. I'm at the tip Harbour 2.0.0beta3 (Rev. 12877) I only set HB_COMPILER=bcc (since I have a couple others installed) That's the reason. If you do this, the build system will not be able to automatically configure BCC. 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:[12878] trunk/harbour
Revision: 12878 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12878view=rev Author: vszakats Date: 2009-11-15 02:52:43 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 03:50 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/win/bcc.mk + Changed to use ilink32 directly to link executables instead of relying on bcc32. This changed synced this details with hbmk2. Please test, especially on Linux+Wine. Also please don't hesitate to make adjustments to this change if needed. BCC isn't my bread and butter and I didn't make extensive tests. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/win/bcc.mk 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] SF.net SVN: harbour-project:[12879] trunk/harbour
Revision: 12879 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12879view=rev Author: vszakats Date: 2009-11-15 03:23:21 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 04:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * config/global.mk * config/win/bcc.mk + Added hack to hack so that bcc autoconfiguration works even when bcc is explicitly selected. Now I wonder what will be the next corner case bcc users will come up with. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/config/global.mk trunk/harbour/config/win/bcc.mk 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] SF.net SVN: harbour-project:[12880] trunk/harbour
Revision: 12880 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12880view=rev Author: vszakats Date: 2009-11-15 04:22:05 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 05:12 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/compiler/genc.c * src/compiler/gencc.c * Using HB_BYTE instead of BYTE in generated .c sources. * contrib/Makefile + contrib/hbsms + contrib/hbsms/Makefile + contrib/hbsms/hbsms.hbc + contrib/hbsms/hbsms.prg + contrib/hbsms/tests + contrib/hbsms/tests/hbmk.hbm + contrib/hbsms/tests/send.prg + Added SMS library. Currently sending is implemented. SMS_SEND( cPort, cPhoneNumber, cText, [lDeliveryReport], [cPIN] ) - nErrorCode. 0 = success ; Uses hbtpathy. * contrib/hbwin/tests/hbmk.hbm ! Missing -es2. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/Makefile trunk/harbour/contrib/hbwin/tests/hbmk.hbm trunk/harbour/src/compiler/genc.c trunk/harbour/src/compiler/gencc.c Added Paths: --- trunk/harbour/contrib/hbsms/ trunk/harbour/contrib/hbsms/Makefile trunk/harbour/contrib/hbsms/hbsms.hbc trunk/harbour/contrib/hbsms/hbsms.prg trunk/harbour/contrib/hbsms/tests/ trunk/harbour/contrib/hbsms/tests/hbmk.hbm trunk/harbour/contrib/hbsms/tests/send.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] SF.net SVN: harbour-project:[12881] trunk/harbour
Revision: 12881 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12881view=rev Author: vszakats Date: 2009-11-15 04:31:21 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 05:30 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbsms/Makefile ! Fixed dependency on tpathy headers. * contrib/hbsms/hbsms.prg * contrib/hbsms/hbsms.hbc - Deleted implementation based on hbwin com port support. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbsms/Makefile trunk/harbour/contrib/hbsms/hbsms.hbc trunk/harbour/contrib/hbsms/hbsms.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] SF.net SVN: harbour-project:[12882] trunk/harbour
Revision: 12882 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12882view=rev Author: vszakats Date: 2009-11-15 05:35:50 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 06:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbqt/hbqt_destruct.cpp ! Fixed the way windows.h is included. ! Fixed to exclude Windows stuff on non-Windows systems (in debug mode). ; PLEASE KEEP IT THIS WAY. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_destruct.cpp 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] SF.net SVN: harbour-project:[12883] trunk/harbour
Revision: 12883 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12883view=rev Author: vouchcac Date: 2009-11-15 06:14:05 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-14 22:05 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/gtwvg/Makefile * contrib/gtwvg/wvgsysw.prg * contrib/gtwvg/wvgwing.c * contrib/gtwvg/wvgwnd.prg - contrib/gtwvg/wincallb.c - contrib/gtwvg/wincback.prg * contrib/gtwvg/tests/demoxbp.prg ! Removed 32 bits only code which made GTWVG unusable on 64 bits opering systems. I just discoved a way to assign WndProc to system dialogs and hence this major change is effected. Viktor, please let me know if GTWVG now compiles fine on 64 bits. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/Makefile trunk/harbour/contrib/gtwvg/tests/demoxbp.prg trunk/harbour/contrib/gtwvg/wvgsysw.prg trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/gtwvg/wvgwnd.prg Removed Paths: - trunk/harbour/contrib/gtwvg/wincallb.c trunk/harbour/contrib/gtwvg/wincback.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] SF.net SVN: harbour-project:[12884] trunk/harbour
Revision: 12884 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12884view=rev Author: vouchcac Date: 2009-11-15 06:25:17 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-14 22:21 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt_slots.cpp * contrib/hbqt/hbqt_slots.h ! Fixed double freeing of HbDbfModel::block because of recalling the same function twice. Przemek ValGrind really helped here, thanks. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt_slots.cpp trunk/harbour/contrib/hbqt/hbqt_slots.h 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:[12883] trunk/harbour
Hi Pritpal, Yes, now it compiles fine and even the demo works when I use msvc64. (I have to turn off warnings to make demowvg.prg compile, these should better be fixed) Some icons don't appear on the toolbar, only a white box is visible (Calendar, Index, Hide). With msvc64, I'm getting this warning, which seems to be a valid one: ../../../wvgutils.c(1256) : warning C4244: 'argument' : conversion from 'HB_PTRDIFF' to 'ULONG', possible loss of data With pocc64, I'm getting this warning: ../../../wvgsink.c(308): warning #2027: Missing prototype for 'hb_oleVariantUpdate'. With mingw64, I getting these errors (some of these may be mingw64 problems): --- i686-w64-mingw32-gcc -I../../../../../contrib/hbwin -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -DUNICODE -ogtwvg.o -c ../../../gtwvg.c In file included from ../../../gtwvg.h:78:0, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/commctrl.h:14:2: error: #error _WIN32_IE setting conflicts In file included from ../../../gtwvg.h:86:0, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlobj.h:14:2: error: #error _WIN32_IE setting conflicts In file included from z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlobj.h:88:0, from ../../../gtwvg.h:86, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlguid.h:13:2: error: #error _WIN32_IE setting conflicts In file included from z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlobj.h:98:0, from ../../../gtwvg.h:86, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1763:69: error: expected declaration specifiers or '...' before 'SHCOLUMNID' z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1764:80: error: expected declaration specifiers or '...' before 'SHCOLUMNID' z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1765:68: error: expected declaration specifiers or '...' before 'SHCOLUMNID' z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1786:86: error: expected declaration specifiers or '...' before 'SHCOLUMNID' z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1788:97: error: expected declaration specifiers or '...' before 'SHCOLUMNID' z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shobjidl.h:1790:85: error: expected declaration specifiers or '...' before 'SHCOLUMNID' In file included from ../../../gtwvg.h:86:0, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlobj.h:1672:5: error: expected specifier-qualifier-list before 'SHCOLUMNID' In file included from ../../../gtwvg.h:86:0, from ../../../gtwvg.c:90: z:/devl/mingw-450-64/lib/gcc/../../i686-w64-mingw32/include/shlobj.h:1715:35: error: expected declaration specifiers or '...' before 'LPCSHCOLUMNID' mingw64-make.exe[1]: *** [gtwvg.o] Error 1 mingw64-make.exe: *** [descend] Error 2 --- Brgds, Viktor On 2009 Nov 15, at 07:14, vouch...@users.sourceforge.net wrote: Revision: 12883 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12883view=rev Author: vouchcac Date: 2009-11-15 06:14:05 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-14 22:05 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/gtwvg/Makefile * contrib/gtwvg/wvgsysw.prg * contrib/gtwvg/wvgwing.c * contrib/gtwvg/wvgwnd.prg - contrib/gtwvg/wincallb.c - contrib/gtwvg/wincback.prg * contrib/gtwvg/tests/demoxbp.prg ! Removed 32 bits only code which made GTWVG unusable on 64 bits opering systems. I just discoved a way to assign WndProc to system dialogs and hence this major change is effected. Viktor, please let me know if GTWVG now compiles fine on 64 bits. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/Makefile trunk/harbour/contrib/gtwvg/tests/demoxbp.prg trunk/harbour/contrib/gtwvg/wvgsysw.prg trunk/harbour/contrib/gtwvg/wvgwing.c trunk/harbour/contrib/gtwvg/wvgwnd.prg Removed Paths: - trunk/harbour/contrib/gtwvg/wincallb.c trunk/harbour/contrib/gtwvg/wincback.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
Re: [Harbour] SF.net SVN: harbour-project:[12874] trunk/harbour
With BCC32 and Rev12884 I get the following warnings: Warning W8004 ../../../HBI18N1.C 238: 'n10' is assigned a value that is never used in function hb_i18n_pluralindex Warning W8004 ../../../HBI18N1.C 238: 'n10' is assigned a value that is never used in function hb_i18n_pluralindex Chen. ___ 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:[12885] trunk/harbour
Revision: 12885 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12885view=rev Author: vszakats Date: 2009-11-15 07:22:25 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 08:21 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/hbi18n1.c ! Fixed bcc warning in recent commit. * contrib/gtwvg/tests/demoxbp.prg ! Fixed to use HB_SYMBOL_UNUSED() instead of local solution. * contrib/gtwvg/tests/demowvg.prg + Added dirbase to icon filenames * contrib/gtwvg/Makefile + Enabled for msvc64 and pocc64. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/Makefile trunk/harbour/contrib/gtwvg/tests/demowvg.prg trunk/harbour/contrib/gtwvg/tests/demoxbp.prg trunk/harbour/src/rtl/hbi18n1.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] hbmk2: embedded Harbour and -bldf
I built Harbour with set HB_USER_PRGFLAGS=-l- (thats a lowercase 'L') ---tt55.prg--- proc main quot(Hello) return -- ..\bin\hbmk2 -bldf tt55 -w -n Harbour 2.0.0beta3 (Rev. 12884) Copyright (c) 1999-2009, http://www.harbour-project.org/ Compiling 'tt55.prg'... Lines 3, Functions/Procedures 1 Generating C source output to 'tt55.c'... Done. Cannot open -l-.prg, assumed external No code generated. hbmk2: Error: Running Harbour compiler (embedded). 1 (E:\hrb\bin\harbour.exe) -n2 tt55.prg -l- -w -n -iE:\hrb\include The following do work: ..\bin\hbmk2 -l- tt55 -w -n Chen. ___ 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:[12883] trunk/harbour
Hi Pritpal, Yes, now it compiles fine and even the demo works when I use msvc64. (I have to turn off warnings to make demowvg.prg compile, these should better be fixed) With mingw32 , @set HB_BUILD_OPTIM=yes @set HB_BUILD_UNICODE=yes @set HB_BUILD_MODE=cpp @set HB_USER_PRGFLAGS=-D__HB_OUTDEBUG__ @set HB_USER_PRGFLAGS=-D__HB_WINDEBUG__ @set HB_USER_PRGFLAGS=-D__debug__ @set HB_USER_CFLAGS=-D__HB_OUTDEBUG__ @set HB_USER_CFLAGS=-D__HB_WINDEBUG__ @set HB_USER_CFLAGS=-D__debug__ I getting this error: g++ -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mtune=pentiumpro -DUNICODE -IC:/Qt/2009.04/qt/include -IC:/Qt/2009.04/qt/include/Qt -IC:/Qt/2009.04/qt/include/QtCore -IC:/Qt/2009.04/qt/include/QtGui -IC:/Qt/2009.04/qt/include/QtNetwork -IC:/Qt/2009.04/qt/include/QtWebKit -D__debug__ -ohbqt_destruct.o -c ../../../hbqt_destruct.cpp ../../../hbqt_destruct.cpp: In function 'void just_debug(const char*, ...)': ../../../hbqt_destruct.cpp:123: error: cannot convert 'char*' to 'const WCHAR*' for argument '1' to 'void OutputDebugStringW(const WCHAR*)' win-make[3]: *** [hbqt_destruct.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [hbqt.inst] Error 2 win-make: *** [contrib.inst] Error 2 Best regards, István ___ 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:[12886] trunk/harbour
Revision: 12886 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12886view=rev Author: vszakats Date: 2009-11-15 07:38:25 + (Sun, 15 Nov 2009) Log Message: --- 2009-11-15 08:37 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * utils/hbmk2/hbmk2.prg ! Fixed typo causing build-time flags to not be recognized when using embedded Harbour compiler and -bldf option. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbmk2/hbmk2.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] Partial classes
Hi all,
I would like your opinion about the concept of 'partial class'. For example:
//--- First.prg
Class MyClass
DATA data1
METHOD MyMethod()
EndClass
METHOD MyMethod() CLASS MyClass
Return Self
//--- Second.Prg
PartialClass MyClass
DATA data2
METHOD MyMethod()
EndClass
METHOD MyMethod() CLASS MyClass
RETURN {::Data1, ::Data2}
In this hyphotetic example a unic class is divided into two diferents prg and
the result is the sum of the two classes.
Could it be implemented in Harbour??
What is your opinion about that??
Thanks and regards,
José Luis Capel
___
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:[12883] trunk/harbour
pls hold on I'll clean the whole debug stuff in both hbxbp and hbqt. Brgds, Viktor On 2009 Nov 15, at 08:35, Bisz István wrote: Hi Pritpal, Yes, now it compiles fine and even the demo works when I use msvc64. (I have to turn off warnings to make demowvg.prg compile, these should better be fixed) With mingw32 , @set HB_BUILD_OPTIM=yes @set HB_BUILD_UNICODE=yes @set HB_BUILD_MODE=cpp @set HB_USER_PRGFLAGS=-D__HB_OUTDEBUG__ @set HB_USER_PRGFLAGS=-D__HB_WINDEBUG__ @set HB_USER_PRGFLAGS=-D__debug__ @set HB_USER_CFLAGS=-D__HB_OUTDEBUG__ @set HB_USER_CFLAGS=-D__HB_WINDEBUG__ @set HB_USER_CFLAGS=-D__debug__ I getting this error: g++ -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mtune=pentiumpro -DUNICODE -IC:/Qt/2009.04/qt/include -IC:/Qt/2009.04/qt/include/Qt -IC:/Qt/2009.04/qt/include/QtCore -IC:/Qt/2009.04/qt/include/QtGui -IC:/Qt/2009.04/qt/include/QtNetwork -IC:/Qt/2009.04/qt/include/QtWebKit -D__debug__ -ohbqt_destruct.o -c ../../../hbqt_destruct.cpp ../../../hbqt_destruct.cpp: In function 'void just_debug(const char*, ...)': ../../../hbqt_destruct.cpp:123: error: cannot convert 'char*' to 'const WCHAR*' for argument '1' to 'void OutputDebugStringW(const WCHAR*)' win-make[3]: *** [hbqt_destruct.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [hbqt.inst] Error 2 win-make: *** [contrib.inst] Error 2 Best regards, István ___ 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
