subject:"\\\[Harbour\\\] Demoqt"


Hi Pritpal

In STATIC FUNCTION Dialogs You are using local oDlg which
is overwriten many times (you should delete QWidgets pointed to by it,
before allocating new ones)

One solution (not going in other leaks) is this:


PROCEDURE Main()
   Local oLabel, oBtn, oDA, oTabBar
   Local oWnd, oSize
   Local oMenuBar, pIcon
   Local oMenuA, pAction
   LOCAL oPS, oPPrv, oMB, oWZ, oCD, oWP, oSBar, oStyle
     Add code
   PUBLIC oDlg1:=oDlg2:=oDlg3:=oDlg4:=oDlg5:=oDlg6:=Nil
   *



STATIC FUNCTION Dialogs( cType, w, l )

local oUrl

   DO CASE
   CASE cType == PageSetup
  if oDlg1 ==Nil
 oDlg1 := QPageSetupDialog():new()
 oDlg1:setWindowTitle( Harbour-QT čššPageSetup Dialog )
  endif
  oDlg1:show()
   CASE cType == Preview
  if oDlg2 ==Nil
 oDlg2 := QPrintPreviewDialog():new()
 oDlg2:setWindowTitle( Harbour-QT Preview Dialog )
  endif
  oDlg2:show()
   CASE cType == Wizard
  if oDlg3 ==Nil
 oDlg3 := QWizard():new()
 oDlg3:setWindowTitle( Harbour-QT Wizard to Show Slides etc. )
  endif
  oDlg3:show()
   CASE cType == Colors
  if oDlg4 ==Nil
 oDlg4 := QColorDialog():new()
 oDlg4:setWindowTitle( Harbour-QT Color Selection Dialog )
  endif
  oDlg4:show()
  
   CASE cType == WebPage
  if oDlg5 ==Nil
 oDlg5 := QWebView():new()
 oUrl := QUrl():new()
 oUrl:setUrl( http://www.harbour.vouch.info; )
 QT_QWebView_SetUrl( QT_PTROF( oDlg5 ), QT_PTROF( oUrl ) )
 oDlg5:setWindowTitle( Harbour-QT Web Page Navigator )
  endif
  oDlg5:show()
   CASE cType == Fonts
  if oDlg6 ==Nil
 oDlg6 := QFontDialog():new()
 oDlg6:setWindowTitle( Harbour-QT Font Selector )
  endif
  oDlg6:show()
   ENDCASE

   RETURN nil


Qbjects are automaticaly destroyed only if they have parent   (
QSomeWidget:New(parent) )
When parent is destroyed, he destroys it's children to.

BRGS
Franček


Pritpal Bedi wrote:
 
 Hi István
 
 
 Bisz István wrote:
 
 The demoqt tests with debug_new shows a lot of leaked objects , see
 attached debug_new.txt. As I see now, the objects allocated by the new
 operator are not released by a corresponding delete operator.
 
 
 I am struggling with this aspect since 20 days and 
 could not reached to any consclusion why Qt is not releasing the 
 objects. To illustrate, just navigate in Brw tab in demoxbp and 
 also keep an eye over task manager. You will be surprized to 
 observe that memory keeps on growing all the time.
 Not only here, just move the mouse in/out of the 
 demoxbp window, the same behavior will follow.
 And the worse is, if you play like this for a 
 couple of hours, netxt time, demoxbp.exe will fail to 
 load. You will need to reboot your computer.
 
 I was wondering why this happens. I rewrote and 
 subclassed QMainWindow() and implemented it for 
 XbpDialog() class to have finer control over events 
 and their execution. However I could not avoid this behavior.
 
 And today you have confirmed that Qt itself is buggy on this front.
 
 Even I downloaded Qt 2009.03 and checked all above against it
 but the result is the same.
 
 Along with above issue, I have one more issue with Qt in 
 respect to its paint engine which fails on MT scenario.
 I will post the modified code and will show what is needed to 
 control it and what heavy penalty we have to pay.
 
 And thanks for stopping my frustration over the subject.
 
 Regards
 Pritpal Bedi
 
 

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25467896.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-16 Thread Viktor Szakáts



On 2009.09.16., at 10:16, Franček Prijatelj wrote:



Hi Pritpal

In STATIC FUNCTION Dialogs You are using local oDlg which
is overwriten many times (you should delete QWidgets pointed to by it,
before allocating new ones)

One solution (not going in other leaks) is this:


PROCEDURE Main()
  Local oLabel, oBtn, oDA, oTabBar
  Local oWnd, oSize
  Local oMenuBar, pIcon
  Local oMenuA, pAction
  LOCAL oPS, oPPrv, oMB, oWZ, oCD, oWP, oSBar, oStyle
    Add code
  PUBLIC oDlg1:=oDlg2:=oDlg3:=oDlg4:=oDlg5:=oDlg6:=Nil
  *


Sorry to jump in, but if there is anything else we
can use instead of PUBLICs we should rather try to
do so. For me it looks bad example to use PUBLIC vars
in example code, as I'd surely wouldn't like to copy
that in any sort of production code. Perhaps a local
array could replace it.

The other thing I don't understand is how is it
possible to create leaks merely by using valid
.prg code? Is it possible to solve this problem
so that such thing cannot happen? Is there a manual
way to free these objects?

Brgds,
Viktor

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi


Franček Prijatelj wrote:
 
 In STATIC FUNCTION Dialogs You are using local oDlg which
 is overwriten many times (you should delete QWidgets pointed to by it,
 before allocating new ones)
 
 One solution (not going in other leaks) is this:
 

I never make tests on demoqt, all is based on demoxbp.

Please find some time to do exactly what I pointed out.
In that scenario, I am not creating/deleting any new objects.
I just want to formulate any strategy which may lead to 
avoid this. Otherwise I am afraid Harbour may not be 
utilizing this fantastic library for industrial strength 
applications.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25468076.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi Victor

I wanted to say (one dirty solution ...)
Here is another using static instead of PUBLIC ...


STATIC FUNCTION Dialogs( cType, w, l )
static oDlg,oDlg2,oDlg3,oDlg4,oDlg5,oDlg6
local oUrl

   DO CASE
   CASE cType == PageSetup
  if oDlg1 ==Nil
 oDlg1 := QPageSetupDialog():new()
 oDlg1:setWindowTitle( Harbour-QT čššPageSetup Dialog )
  endif
  oDlg1:show()
   CASE cType == Preview
  if oDlg2 ==Nil
 oDlg2 := QPrintPreviewDialog():new()
 oDlg2:setWindowTitle( Harbour-QT Preview Dialog )
  endif
  oDlg2:show()
   CASE cType == Wizard
  if oDlg3 ==Nil
 oDlg3 := QWizard():new()
 oDlg3:setWindowTitle( Harbour-QT Wizard to Show Slides etc. )
  endif
  oDlg3:show()
   CASE cType == Colors
  if oDlg4 ==Nil
 oDlg4 := QColorDialog():new()
 oDlg4:setWindowTitle( Harbour-QT Color Selection Dialog )
  endif
  oDlg4:show()
  
   CASE cType == WebPage
  if oDlg5 ==Nil
 oDlg5 := QWebView():new()
 oUrl := QUrl():new()
 oUrl:setUrl( http://www.harbour.vouch.info; )
 QT_QWebView_SetUrl( QT_PTROF( oDlg5 ), QT_PTROF( oUrl ) )
 oDlg5:setWindowTitle( Harbour-QT Web Page Navigator )
  endif
  oDlg5:show()
   CASE cType == Fonts
  if oDlg6 ==Nil
 oDlg6 := QFontDialog():new()
 oDlg6:setWindowTitle( Harbour-QT Font Selector )
  endif
  oDlg6:show()
   ENDCASE

   RETURN nil

My intention was to show why webpage when visited increases size
of used memory.
With this solution memory is increased only first time.
Of course, there are better solutions.

BRGS
Franček


Viktor Szakáts wrote:
 
 
 On 2009.09.16., at 10:16, Franček Prijatelj wrote:
 

 Hi Pritpal

 In STATIC FUNCTION Dialogs You are using local oDlg which
 is overwriten many times (you should delete QWidgets pointed to by it,
 before allocating new ones)

 One solution (not going in other leaks) is this:


 PROCEDURE Main()
   Local oLabel, oBtn, oDA, oTabBar
   Local oWnd, oSize
   Local oMenuBar, pIcon
   Local oMenuA, pAction
   LOCAL oPS, oPPrv, oMB, oWZ, oCD, oWP, oSBar, oStyle
     Add code
   PUBLIC oDlg1:=oDlg2:=oDlg3:=oDlg4:=oDlg5:=oDlg6:=Nil
   *
 
 Sorry to jump in, but if there is anything else we
 can use instead of PUBLICs we should rather try to
 do so. For me it looks bad example to use PUBLIC vars
 in example code, as I'd surely wouldn't like to copy
 that in any sort of production code. Perhaps a local
 array could replace it.
 
 The other thing I don't understand is how is it
 possible to create leaks merely by using valid
 .prg code? Is it possible to solve this problem
 so that such thing cannot happen? Is there a manual
 way to free these objects?
 
 Brgds,
 Viktor
 
 ___
 Harbour mailing list
 Harbour@harbour-project.org
 http://lists.harbour-project.org/mailman/listinfo/harbour
 
 

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25468128.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-16 Thread Viktor Szakáts


Hi Francek,

Okay, I see, although I'm still concerned that these
objects are never freed, and if I'd like to free them,
what is the right way to do it?

Brgds,
Viktor

On 2009.09.16., at 10:33, Franček Prijatelj wrote:



Hi Victor

I wanted to say (one dirty solution ...)
Here is another using static instead of PUBLIC ...


STATIC FUNCTION Dialogs( cType, w, l )
static oDlg,oDlg2,oDlg3,oDlg4,oDlg5,oDlg6
local oUrl

  DO CASE
  CASE cType == PageSetup
 if oDlg1 ==Nil
oDlg1 := QPageSetupDialog():new()
oDlg1:setWindowTitle( Harbour-QT čššPageSetup Dialog )
 endif
 oDlg1:show()
  CASE cType == Preview
 if oDlg2 ==Nil
oDlg2 := QPrintPreviewDialog():new()
oDlg2:setWindowTitle( Harbour-QT Preview Dialog )
 endif
 oDlg2:show()
  CASE cType == Wizard
 if oDlg3 ==Nil
oDlg3 := QWizard():new()
oDlg3:setWindowTitle( Harbour-QT Wizard to Show Slides  
etc. )

 endif
 oDlg3:show()
  CASE cType == Colors
 if oDlg4 ==Nil
oDlg4 := QColorDialog():new()
oDlg4:setWindowTitle( Harbour-QT Color Selection Dialog )
 endif
 oDlg4:show()

  CASE cType == WebPage
 if oDlg5 ==Nil
oDlg5 := QWebView():new()
oUrl := QUrl():new()
oUrl:setUrl( http://www.harbour.vouch.info; )
QT_QWebView_SetUrl( QT_PTROF( oDlg5 ), QT_PTROF( oUrl ) )
oDlg5:setWindowTitle( Harbour-QT Web Page Navigator )
 endif
 oDlg5:show()
  CASE cType == Fonts
 if oDlg6 ==Nil
oDlg6 := QFontDialog():new()
oDlg6:setWindowTitle( Harbour-QT Font Selector )
 endif
 oDlg6:show()
  ENDCASE

  RETURN nil

My intention was to show why webpage when visited increases size
of used memory.
With this solution memory is increased only first time.
Of course, there are better solutions.

BRGS
Franček


Viktor Szakáts wrote:



On 2009.09.16., at 10:16, Franček Prijatelj wrote:



Hi Pritpal

In STATIC FUNCTION Dialogs You are using local oDlg which
is overwriten many times (you should delete QWidgets pointed to by  
it,

before allocating new ones)

One solution (not going in other leaks) is this:


PROCEDURE Main()
 Local oLabel, oBtn, oDA, oTabBar
 Local oWnd, oSize
 Local oMenuBar, pIcon
 Local oMenuA, pAction
 LOCAL oPS, oPPrv, oMB, oWZ, oCD, oWP, oSBar, oStyle
   Add code
 PUBLIC oDlg1:=oDlg2:=oDlg3:=oDlg4:=oDlg5:=oDlg6:=Nil
 *


Sorry to jump in, but if there is anything else we
can use instead of PUBLICs we should rather try to
do so. For me it looks bad example to use PUBLIC vars
in example code, as I'd surely wouldn't like to copy
that in any sort of production code. Perhaps a local
array could replace it.

The other thing I don't understand is how is it
possible to create leaks merely by using valid
.prg code? Is it possible to solve this problem
so that such thing cannot happen? Is there a manual
way to free these objects?

Brgds,
Viktor

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




--
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25468128.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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


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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi Victor

In this particular case I see no problem.
Maybe we want to keep a state in every tab.
If not (maybe we are short on memory ..), 
we can delete objects when we loose focus on particular tab.
Anyhow memory is reclaimed at the end of app.

Regards 
Franček


Viktor Szakáts wrote:
 
 Hi Francek,
 
 Okay, I see, although I'm still concerned that these
 objects are never freed, and if I'd like to free them,
 what is the right way to do it?
 
 Brgds,
 Viktor
 
 On 2009.09.16., at 10:33, Franček Prijatelj wrote:
 

 Hi Victor

 I wanted to say (one dirty solution ...)
 Here is another using static instead of PUBLIC ...


 STATIC FUNCTION Dialogs( cType, w, l )
 static oDlg,oDlg2,oDlg3,oDlg4,oDlg5,oDlg6
 local oUrl

   DO CASE
   CASE cType == PageSetup
  if oDlg1 ==Nil
 oDlg1 := QPageSetupDialog():new()
 oDlg1:setWindowTitle( Harbour-QT čššPageSetup Dialog )
  endif
  oDlg1:show()
   CASE cType == Preview
  if oDlg2 ==Nil
 oDlg2 := QPrintPreviewDialog():new()
 oDlg2:setWindowTitle( Harbour-QT Preview Dialog )
  endif
  oDlg2:show()
   CASE cType == Wizard
  if oDlg3 ==Nil
 oDlg3 := QWizard():new()
 oDlg3:setWindowTitle( Harbour-QT Wizard to Show Slides  
 etc. )
  endif
  oDlg3:show()
   CASE cType == Colors
  if oDlg4 ==Nil
 oDlg4 := QColorDialog():new()
 oDlg4:setWindowTitle( Harbour-QT Color Selection Dialog )
  endif
  oDlg4:show()

   CASE cType == WebPage
  if oDlg5 ==Nil
 oDlg5 := QWebView():new()
 oUrl := QUrl():new()
 oUrl:setUrl( http://www.harbour.vouch.info; )
 QT_QWebView_SetUrl( QT_PTROF( oDlg5 ), QT_PTROF( oUrl ) )
 oDlg5:setWindowTitle( Harbour-QT Web Page Navigator )
  endif
  oDlg5:show()
   CASE cType == Fonts
  if oDlg6 ==Nil
 oDlg6 := QFontDialog():new()
 oDlg6:setWindowTitle( Harbour-QT Font Selector )
  endif
  oDlg6:show()
   ENDCASE

   RETURN nil

 My intention was to show why webpage when visited increases size
 of used memory.
 With this solution memory is increased only first time.
 Of course, there are better solutions.

 BRGS
 Franček


 Viktor Szakáts wrote:


 On 2009.09.16., at 10:16, Franček Prijatelj wrote:


 Hi Pritpal

 In STATIC FUNCTION Dialogs You are using local oDlg which
 is overwriten many times (you should delete QWidgets pointed to by  
 it,
 before allocating new ones)

 One solution (not going in other leaks) is this:


 PROCEDURE Main()
  Local oLabel, oBtn, oDA, oTabBar
  Local oWnd, oSize
  Local oMenuBar, pIcon
  Local oMenuA, pAction
  LOCAL oPS, oPPrv, oMB, oWZ, oCD, oWP, oSBar, oStyle
    Add code
  PUBLIC oDlg1:=oDlg2:=oDlg3:=oDlg4:=oDlg5:=oDlg6:=Nil
  *

 Sorry to jump in, but if there is anything else we
 can use instead of PUBLICs we should rather try to
 do so. For me it looks bad example to use PUBLIC vars
 in example code, as I'd surely wouldn't like to copy
 that in any sort of production code. Perhaps a local
 array could replace it.

 The other thing I don't understand is how is it
 possible to create leaks merely by using valid
 .prg code? Is it possible to solve this problem
 so that such thing cannot happen? Is there a manual
 way to free these objects?

 Brgds,
 Viktor

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



 -- 
 View this message in context:
 http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25468128.html
 Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25468576.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hello Viktor


Viktor Szakáts wrote:
 
 This means QT cannot be used in apps which is supposed
 to run continuously. (?)
 
 Continuously running GUI apps aren't that typical, but
 to me it's still a serious concern that and app just
 eats memory while running. This makes it f.e. unsuitable
 for any sort of embedded GUI applications (like a kiosk).
 
 Is this a property of QT itself, or the property of
 Harbour wrappers?
 

It is a property of Qt itself.
I have made extensive experiments as far as Harbour's 
parameter passing is concerned and have reached to the 
conclusion that it is harmless. Experiments with Qt's 
object destruction has given me weired results.
For example:

   oRect := QRect():new( 20,20,30,400 )
   ? oRect:left()  = 20
   ? oRect:top()  = 20
   ? oRect:right() = 30
   ? oRect:bottom() = 400

   Qt_QRect_destroy( oRect )
   ? oRect:left()  = 4534342  ( a long figure )
   ? oRect:top()  = 8967354  ( another long figure )
   ? oRect:right() = 30 
   ? oRect:bottom() = 400
   
.cpp

   HB_FUNC( QT_QRECT_DESTROY )
   {
  delete hbqt_par_QRect( 1 );   
  //  OR/AND
  hbqt_par_QRect( 1 )-~QRect();
   }

So even after destroy, oRect is an active pointer and 
only firts two slots are pointing to garbase. In theory 
after destroying it it should raise som error or appln
must hang, but results are contrary.
   
Though I have not given up, YET, on this issue,
but at the face value ( till now ) it appears we cannot 
use Harbour-Qt for production level applications.

NOTE: struggle is still on to overcome it.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25474420.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-16 Thread Viktor Szakáts


Hi Pritpal,


Is this a property of QT itself, or the property of
Harbour wrappers?



It is a property of Qt itself.
I have made extensive experiments as far as Harbour's
parameter passing is concerned and have reached to the
conclusion that it is harmless. Experiments with Qt's
object destruction has given me weired results.
For example:

  oRect := QRect():new( 20,20,30,400 )
  ? oRect:left()  = 20
  ? oRect:top()  = 20
  ? oRect:right() = 30
  ? oRect:bottom() = 400

  Qt_QRect_destroy( oRect )
  ? oRect:left()  = 4534342  ( a long figure )
  ? oRect:top()  = 8967354  ( another long figure )
  ? oRect:right() = 30
  ? oRect:bottom() = 400

.cpp

  HB_FUNC( QT_QRECT_DESTROY )
  {
 delete hbqt_par_QRect( 1 );
 //  OR/AND
 hbqt_par_QRect( 1 )-~QRect();
  }

So even after destroy, oRect is an active pointer and
only firts two slots are pointing to garbase. In theory
after destroying it it should raise som error or appln
must hang, but results are contrary.

Though I have not given up, YET, on this issue,
but at the face value ( till now ) it appears we cannot
use Harbour-Qt for production level applications.

NOTE: struggle is still on to overcome it.


Thanks for the explanation and details.

Could it be that QT uses some sort of lazy freeing of the
objects (f.e. to keep user apps not crash when doing object
access after freeing, and/or to maintain compatibility with
earlier QT lib releases, or there could be others reasons
also), so that actual freeing happens only later in a
gc-like phase? If so, maybe there is a way to control that
directly or indirectly.

Looks like an issue which would make QT unsuitable for
a lot of uses (embedded systems), so I'd guess they have
solved this issue somehow.

Some easy googling gave this result:
http://lists.trolltech.com/pipermail/qt-interest/2008-December/000458.html

This might help understanding its internals.

Brgds,
Viktor

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

RE: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-16 Thread Bisz István

Hi,

continuing the leaked objects issue, based on the sample sent by Pritpal... 

#define QT_PTROF( oObj )  ( oObj:pPtr )

PROCEDURE Main()
   Local oRect

   oRect := QRect():new( 20,20,30,400 )

   ? oRect:left()
   ? oRect:top()
   ? oRect:right()
   ? oRect:bottom()

/*
   Qt_QRect_destroy( QT_PTROF( oRect ) )
   or
   oRect:Destroy()
*/
   oRect:Destroy()

   RETURN

I executed the following test cases with debug_new:
 
Case 1:

   // With this cpp function
   // See: leakobj_with_delete.txt
   HB_FUNC( QT_QRECT_DESTROY )
   {
  //hbqt_par_QRect( 1 )-~QRect();
  delete hbqt_par_QRect( 1 );
   }

Case 2:


   // With this cpp function
   // See: leakobj_without_delete.txt
   HB_FUNC( QT_QRECT_DESTROY )
   {
  hbqt_par_QRect( 1 )-~QRect();
  //delete hbqt_par_QRect( 1 );
   }

Case 3:

   // With this cpp function
   // See: leakobj_with_destructor_and_delete.txt
   HB_FUNC( QT_QRECT_DESTROY )
   {
  hbqt_par_QRect( 1 )-~QRect();
  delete hbqt_par_QRect( 1 );
   }

The resulted log files are attached.

The reserved heap size at the end goes to zero just in test case 1 and 3.
'delete: freed 0x80b5a60 (size 4, 0 bytes still allocated)'.
Test case 2 shows that QRect (with size 16 bytes) allocated by Qt remains on
the heap. 'delete: freed 0x8e8aa60 (size 4, 16 bytes still allocated).

Pritpal, could you please insert the delete operator in the destructors
logic? An another solution is to define a new Delete() method containing
just the delete operator.
In any case this second solution will help the further investigations.

Best regards,
István

-Original Message-
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2009. szeptember 16. 17:19
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoqt tests with debug_new - Leaked objects

Hi Pritpal,

 Is this a property of QT itself, or the property of
 Harbour wrappers?


 It is a property of Qt itself.
 I have made extensive experiments as far as Harbour's
 parameter passing is concerned and have reached to the
 conclusion that it is harmless. Experiments with Qt's
 object destruction has given me weired results.
 For example:

   oRect := QRect():new( 20,20,30,400 )
   ? oRect:left()  = 20
   ? oRect:top()  = 20
   ? oRect:right() = 30
   ? oRect:bottom() = 400

   Qt_QRect_destroy( oRect )
   ? oRect:left()  = 4534342  ( a long figure )
   ? oRect:top()  = 8967354  ( another long figure )
   ? oRect:right() = 30
   ? oRect:bottom() = 400

 .cpp

   HB_FUNC( QT_QRECT_DESTROY )
   {
  delete hbqt_par_QRect( 1 );
  //  OR/AND
  hbqt_par_QRect( 1 )-~QRect();
   }

 So even after destroy, oRect is an active pointer and
 only firts two slots are pointing to garbase. In theory
 after destroying it it should raise som error or appln
 must hang, but results are contrary.

 Though I have not given up, YET, on this issue,
 but at the face value ( till now ) it appears we cannot
 use Harbour-Qt for production level applications.

 NOTE: struggle is still on to overcome it.

Thanks for the explanation and details.

Could it be that QT uses some sort of lazy freeing of the
objects (f.e. to keep user apps not crash when doing object
access after freeing, and/or to maintain compatibility with
earlier QT lib releases, or there could be others reasons
also), so that actual freeing happens only later in a
gc-like phase? If so, maybe there is a way to control that
directly or indirectly.

Looks like an issue which would make QT unsuitable for
a lot of uses (embedded systems), so I'd guess they have
solved this issue somehow.

Some easy googling gave this result:
http://lists.trolltech.com/pipermail/qt-interest/2008-December/000458.html

This might help understanding its internals.

Brgds,
Viktor

___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Leaked object at 0x86a2a18 (size 4, 0x2192b5d)
Leaked object at 0x86a2a60 (size 4, 0x216632d)
Leaked object at 0x86a2aa8 (size 96, 0x20ef093)
Leaked object at 0x86a2b50 (size 4, 0x2166a1d)
Leaked object at 0x86a2bc0 (size 4, 0x2192f5d)
Leaked object at 0x86a2c08 (size 96, 0x20ef093)
Leaked object at 0x86a2cb0 (size 4, 0x2192e2d)
Leaked object at 0x86a2cf8 (size 20, 0x2193264)
Leaked object at 0x86a4ed0 (size 20, 0x2193264)
Leaked object at 0x86a4f28 (size 20, 0x2193264)
Leaked object at 0x86a4f80 (size 20, 0x2193264)
Leaked object at 0x86a5008 (size 4, 0x21ee6ed)
Leaked object at 0x86a5050 (size 4, 0x21ee5ed)
Leaked object at 0x86a5098 (size 36, 0x20eff86)
Leaked object at 0x86a5100 (size 96, 0x20ef093)
Leaked object at 0x86a51a8 (size 80, 0x20f50c2)
Leaked object at 0x86a5240 (size 80, 0x20f50c2)
Leaked object at 0x86a53f8 (size 20, 0x2193264)
Leaked object at 0x86a5450 (size 20, 0x2193264)
*** 19 leaks found
delete: freed 0x86a5450 (size 20, 612 bytes still allocated)
delete: freed 0x86a53f8 (size 20

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi Pritpal

This behavior is usual for any C++ program.

Here is example:


#include iostream

using namespace std;

class TRect
{
public:
  TRect(int t,int l,int w,int h)
:_t(t),_l(l),_w(w),_h(h)
  {}

  int top()const { return _t; }
  int left()   const { return _l; }
  int width()  const { return _w; }
  int height() const { return _h; }

private:
  int _t,_l,_w,_h;
};

int main()
{
TRect *r1= new TRect(20,20,30,400);
cout  before delete   endl;
cout  r1-top() endl;
cout  r1-left()endl;
cout  r1-width()   endl;
cout  r1-height()  endl;

delete r1;
cout  after delete   endl;
//r1=0;
cout  r1-top() endl;
cout  r1-left()endl;
cout  r1-width()   endl;
cout  r1-height()  endl;
return 0;
}

/ output  
before delete  
20
20
30
400   
after delete  
0
20
30
400  
/

Because of that it's recomender to set pointers to 0 (r1=0)

Brgs
Franček



Pritpal Bedi wrote:
 
 Hello Viktor
 
 
 Viktor Szakáts wrote:
 
 This means QT cannot be used in apps which is supposed
 to run continuously. (?)
 
 Continuously running GUI apps aren't that typical, but
 to me it's still a serious concern that and app just
 eats memory while running. This makes it f.e. unsuitable
 for any sort of embedded GUI applications (like a kiosk).
 
 Is this a property of QT itself, or the property of
 Harbour wrappers?
 
 
 It is a property of Qt itself.
 I have made extensive experiments as far as Harbour's 
 parameter passing is concerned and have reached to the 
 conclusion that it is harmless. Experiments with Qt's 
 object destruction has given me weired results.
 For example:
 
oRect := QRect():new( 20,20,30,400 )
? oRect:left()  = 20
? oRect:top()  = 20
? oRect:right() = 30
? oRect:bottom() = 400
 
Qt_QRect_destroy( oRect )
? oRect:left()  = 4534342  ( a long figure )
? oRect:top()  = 8967354  ( another long figure )
? oRect:right() = 30 
? oRect:bottom() = 400

 .cpp
 
HB_FUNC( QT_QRECT_DESTROY )
{
   delete hbqt_par_QRect( 1 );   
   //  OR/AND
   hbqt_par_QRect( 1 )-~QRect();
}
 
 So even after destroy, oRect is an active pointer and 
 only firts two slots are pointing to garbase. In theory 
 after destroying it it should raise som error or appln
 must hang, but results are contrary.

 Though I have not given up, YET, on this issue,
 but at the face value ( till now ) it appears we cannot 
 use Harbour-Qt for production level applications.
 
 NOTE: struggle is still on to overcome it.
 
 Regards
 Pritpal Bedi
 
 

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480346.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi

By the way, you shuld newer call x-~TXobj directly.
You !!!MUST delete x

Here is explanation

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.9

BRGS
Franček




Franček Prijatelj wrote:
 
 Hi Pritpal
 
 This behavior is usual for any C++ program.
 
 Here is example:
 
 
 #include iostream
 
 using namespace std;
 
 class TRect
 {
 public:
   TRect(int t,int l,int w,int h)
 :_t(t),_l(l),_w(w),_h(h)
   {}
 
   int top()const { return _t; }
   int left()   const { return _l; }
   int width()  const { return _w; }
   int height() const { return _h; }
 
 private:
   int _t,_l,_w,_h;
 };
 
 int main()
 {
 TRect *r1= new TRect(20,20,30,400);
 cout  before delete   endl;
 cout  r1-top() endl;
 cout  r1-left()endl;
 cout  r1-width()   endl;
 cout  r1-height()  endl;
 
 delete r1;
 cout  after delete   endl;
 //r1=0;
 cout  r1-top() endl;
 cout  r1-left()endl;
 cout  r1-width()   endl;
 cout  r1-height()  endl;
 return 0;
 }
 
 / output  
 before delete  
 20
 20
 30
 400   
 after delete  
 0
 20
 30
 400  
 /
 
 Because of that it's recomender to set pointers to 0 (r1=0)
 
 Brgs
 Franček
 
 
 
 Pritpal Bedi wrote:
 
 Hello Viktor
 
 
 Viktor Szakáts wrote:
 
 This means QT cannot be used in apps which is supposed
 to run continuously. (?)
 
 Continuously running GUI apps aren't that typical, but
 to me it's still a serious concern that and app just
 eats memory while running. This makes it f.e. unsuitable
 for any sort of embedded GUI applications (like a kiosk).
 
 Is this a property of QT itself, or the property of
 Harbour wrappers?
 
 
 It is a property of Qt itself.
 I have made extensive experiments as far as Harbour's 
 parameter passing is concerned and have reached to the 
 conclusion that it is harmless. Experiments with Qt's 
 object destruction has given me weired results.
 For example:
 
oRect := QRect():new( 20,20,30,400 )
? oRect:left()  = 20
? oRect:top()  = 20
? oRect:right() = 30
? oRect:bottom() = 400
 
Qt_QRect_destroy( oRect )
? oRect:left()  = 4534342  ( a long figure )
? oRect:top()  = 8967354  ( another long figure )
? oRect:right() = 30 
? oRect:bottom() = 400

 .cpp
 
HB_FUNC( QT_QRECT_DESTROY )
{
   delete hbqt_par_QRect( 1 );   
   //  OR/AND
   hbqt_par_QRect( 1 )-~QRect();
}
 
 So even after destroy, oRect is an active pointer and 
 only firts two slots are pointing to garbase. In theory 
 after destroying it it should raise som error or appln
 must hang, but results are contrary.

 Though I have not given up, YET, on this issue,
 but at the face value ( till now ) it appears we cannot 
 use Harbour-Qt for production level applications.
 
 NOTE: struggle is still on to overcome it.
 
 Regards
 Pritpal Bedi
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480744.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

RE: [Harbour] demoqt tests with debug_new - Leaked objects


Hi 


Bisz István wrote:
 
 I executed the following test cases with debug_new:
  
 Case 1:
 
// With this cpp function
// See: leakobj_with_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   //hbqt_par_QRect( 1 )-~QRect();
   delete hbqt_par_QRect( 1 );
}
 
 Case 2:
 
 
// With this cpp function
// See: leakobj_without_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   hbqt_par_QRect( 1 )-~QRect();
   //delete hbqt_par_QRect( 1 );
}
 
 Case 3:
 
// With this cpp function
// See: leakobj_with_destructor_and_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   hbqt_par_QRect( 1 )-~QRect();
   delete hbqt_par_QRect( 1 );
}
 
 The resulted log files are attached.
 
 The reserved heap size at the end goes to zero just in test case 1 and 3.
 'delete: freed 0x80b5a60 (size 4, 0 bytes still allocated)'.
 Test case 2 shows that QRect (with size 16 bytes) allocated by Qt remains
 on
 the heap. 'delete: freed 0x8e8aa60 (size 4, 16 bytes still allocated).
 
 Pritpal, could you please insert the delete operator in the destructors
 logic? An another solution is to define a new Delete() method containing
 just the delete operator.
 In any case this second solution will help the further investigations.
 

I have already implemented case 1.
But still experimenting. It is not the case that the memory is 
release properly at the END of the application, I need to have it 
released as soon as an object is destroyed. 

Hopefully we may find a solution with further investigations.
Keep on your good work of debugging and tips.

BTW which is the best case? 1 or 3 ?

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480816.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects


Hi


Franček Prijatelj wrote:
 
 By the way, you shuld newer call x-~TXobj directly.
 You !!!MUST delete x
 
 Here is explanation
 
 http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.9
 

Thanks for digging deep.
Now exactly this approach I have implemented.
Continue further.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480835.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

RE: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-16 Thread Bisz István

Hi,

As I see now, the best way for test purposing is to have two methods one with 
destructor as it is now and a second one with the delete operator. In this case 
it will be possible at 'prg' level to test/design the final destructor for both 
prg class and Qt native class.

Best regards,
István 

-Original Message-
From: harbour-boun...@harbour-project.org 
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Pritpal Bedi
Sent: 2009. szeptember 16. 23:16
To: harbour@harbour-project.org
Subject: RE: [Harbour] demoqt tests with debug_new - Leaked objects


Hi 


Bisz István wrote:
 
 I executed the following test cases with debug_new:
  
 Case 1:
 
// With this cpp function
// See: leakobj_with_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   //hbqt_par_QRect( 1 )-~QRect();
   delete hbqt_par_QRect( 1 );
}
 
 Case 2:
 
 
// With this cpp function
// See: leakobj_without_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   hbqt_par_QRect( 1 )-~QRect();
   //delete hbqt_par_QRect( 1 );
}
 
 Case 3:
 
// With this cpp function
// See: leakobj_with_destructor_and_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
   hbqt_par_QRect( 1 )-~QRect();
   delete hbqt_par_QRect( 1 );
}
 
 The resulted log files are attached.
 
 The reserved heap size at the end goes to zero just in test case 1 and 3.
 'delete: freed 0x80b5a60 (size 4, 0 bytes still allocated)'.
 Test case 2 shows that QRect (with size 16 bytes) allocated by Qt remains
 on
 the heap. 'delete: freed 0x8e8aa60 (size 4, 16 bytes still allocated).
 
 Pritpal, could you please insert the delete operator in the destructors
 logic? An another solution is to define a new Delete() method containing
 just the delete operator.
 In any case this second solution will help the further investigations.
 

I have already implemented case 1.
But still experimenting. It is not the case that the memory is 
release properly at the END of the application, I need to have it 
released as soon as an object is destroyed. 

Hopefully we may find a solution with further investigations.
Keep on your good work of debugging and tips.

BTW which is the best case? 1 or 3 ?

Regards
Pritpal Bedi
-- 
View this message in context: 
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480816.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

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

Re: [Harbour] demoqt tests with debug_new - Leaked objects

2009-09-14 Thread Pritpal Bedi

Hi István

Bisz István wrote:

The demoqt tests with debug_new shows a lot of leaked objects , see
attached debug_new.txt. As I see now, the objects allocated by the new
operator are not released by a corresponding delete operator.

I am struggling with this aspect since 20 days and
could not reached to any consclusion why Qt is not releasing the
objects. To illustrate, just navigate in Brw tab in demoxbp and
also keep an eye over task manager. You will be surprized to
observe that memory keeps on growing all the time.
Not only here, just move the mouse in/out of the
demoxbp window, the same behavior will follow.
And the worse is, if you play like this for a
couple of hours, netxt time, demoxbp.exe will fail to
load. You will need to reboot your computer.

I was wondering why this happens. I rewrote and
subclassed QMainWindow() and implemented it for
XbpDialog() class to have finer control over events
and their execution. However I could not avoid this behavior.

And today you have confirmed that Qt itself is buggy on this front.

Even I downloaded Qt 2009.03 and checked all above against it
but the result is the same.

Along with above issue, I have one more issue with Qt in
respect to its paint engine which fails on MT scenario.
I will post the modified code and will show what is needed to
control it and what heavy penalty we have to pay.

And thanks for stopping my frustration over the subject.

Regards
Pritpal Bedi

--
View this message in context:
http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25440044.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

[Harbour] demoqt working ok in Kubuntu 9.04

I wan't to report that now works ok HBQT and demoqt in Linux
Kubuntu 9.04


you can see an screenshot here :
http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

Good Work

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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

2009-07-01 Thread Massimo Belgrano

Is broken link?

2009/7/1 Bruno Luciani bruno.luci...@gmail.com

 I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

yes for some reason , don't work

wait some minutes i upload to another site

Bruno

2009/7/1 Massimo Belgrano mbelgr...@deltain.it

 Is broken link?

 2009/7/1 Bruno Luciani bruno.luci...@gmail.com

 I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




 --
 Massimo Belgrano



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


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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

Here is a new link , confirm if you can see

Bruno


http://s3.subirimagenes.com:81/imagen/previo/thump_2811257hbqtlinux.png





2009/7/1 Massimo Belgrano mbelgr...@deltain.it

 Is broken link?

 2009/7/1 Bruno Luciani bruno.luci...@gmail.com

 I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




 --
 Massimo Belgrano



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


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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

2009-07-01 Thread Pritpal Bedi


Hi

http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

http://lw3dtr.com.ar/images/hbqt_demo_linux.png

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-working-ok-in-Kubuntu-9.04-tp24292443p24292791.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

http://www.subirimagenes.com/imagen-hbqtlinux-2811257.html


Better here


Bruno

2009/7/1 Bruno Luciani bruno.luci...@gmail.com


 Here is a new link , confirm if you can see

 Bruno


 http://s3.subirimagenes.com:81/imagen/previo/thump_2811257hbqtlinux.png





 2009/7/1 Massimo Belgrano mbelgr...@deltain.it

 Is broken link?


 2009/7/1 Bruno Luciani bruno.luci...@gmail.com

  I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




 --
 Massimo Belgrano



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



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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

2009-07-01 Thread Massimo Belgrano

Yes but is very small

2009/7/1 Bruno Luciani bruno.luci...@gmail.com


 Here is a new link , confirm if you can see

 Bruno


 http://s3.subirimagenes.com:81/imagen/previo/thump_2811257hbqtlinux.png





 2009/7/1 Massimo Belgrano mbelgr...@deltain.it

 Is broken link?


 2009/7/1 Bruno Luciani bruno.luci...@gmail.com

  I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




 --
 Massimo Belgrano



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



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




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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

2009-07-01 Thread Viktor Szakáts


It works here too on Linux. Except for some unfortunate
color combinations (white on almost white) in a few UI
elements in demoxbp, it looks very nice, looks fully
native, and startup is very quick on Linux.

On Ubuntu, libqt4-dev package is needed to build it.

Brgds,
Viktor

On 2009.07.01., at 18:22, Bruno Luciani wrote:



Here is a new link , confirm if you can see

Bruno


http://s3.subirimagenes.com:81/imagen/previo/ 
thump_2811257hbqtlinux.png






2009/7/1 Massimo Belgrano mbelgr...@deltain.it
Is broken link?

2009/7/1 Bruno Luciani bruno.luci...@gmail.com
I wan't to report that now works ok HBQT and demoqt in Linux
Kubuntu 9.04


you can see an screenshot here : 
http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

Good Work

Bruno


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




--
Massimo Belgrano



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


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


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

Re: [Harbour] demoqt working ok in Kubuntu 9.04

2009-07-01 Thread Massimo Belgrano

YesIs impressive


2009/7/1 Bruno Luciani bruno.luci...@gmail.com

 http://www.subirimagenes.com/imagen-hbqtlinux-2811257.html


 Better here


 Bruno


 2009/7/1 Bruno Luciani bruno.luci...@gmail.com


 Here is a new link , confirm if you can see

 Bruno


 http://s3.subirimagenes.com:81/imagen/previo/thump_2811257hbqtlinux.png





 2009/7/1 Massimo Belgrano mbelgr...@deltain.it

 Is broken link?


 2009/7/1 Bruno Luciani bruno.luci...@gmail.com

  I wan't to report that now works ok HBQT and demoqt in Linux
 Kubuntu 9.04


 you can see an screenshot here :
 http://www.lw3dtr.com.ar/images/hbqt_demo_linux.png

 Good Work

 Bruno


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




 --
 Massimo Belgrano



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




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




-- 
Massimo Belgrano

Analisi e sviluppo software per Lan e Web - Consulenza informatica -
Formazione
Delta Informatica S.r.l. http://www.deltain.it/   +39 0321 455962
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

[Harbour] demoqt on linux


Hello

I try to make demoqt  on linux (Ubuntu 9.04)

s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ svn update
At revision 11288.
s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ hbmk2 demoqt.prg
hbmk: Processing configuration: /usr/bin/hbmk.cfg
hbmk: Processing: hbqt.hbc
Harbour 2.0.0beta1 (Rev. 11288)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoqt.prg'...
Lines 738, Functions/Procedures 18
Generating C source output to 'demoqt.c'... Done.
demoqt.prg:727:21: error: windows.h: No such file or directory
hbmk: Error: Running C compiler. 1
gcc -c -O3  -I/usr/include/harbour demoqt.c /tmp/hbmk_ushy5b.c

after coment out  #include windows.h at line 727 I got:

s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ hbmk2 demoqt.prg
hbmk: Processing configuration: /usr/bin/hbmk.cfg
hbmk: Processing: hbqt.hbc
Harbour 2.0.0beta1 (Rev. 11288)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'demoqt.prg'...
Lines 738, Functions/Procedures 18
Generating C source output to 'demoqt.c'... Done.
demoqt.o: In function `HB_FUN_UIDEBUG':
demoqt.c:(.text+0x16): undefined reference to `OutputDebugString'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc demoqt.o hbmk_7jn45m.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
-lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
-Wl,--end-group -odemoqt -L/usr/lib/harbour


best regards
Davor Siklic



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

Re: [Harbour] demoqt on linux


Hi

Welcome onboard.


siki-2 wrote:
 
 Hello
 
 I try to make demoqt  on linux (Ubuntu 9.04)
 
 after coment out  #include windows.h at line 727 I got:
 
 demoqt.o: In function `HB_FUN_UIDEBUG':
 demoqt.c:(.text+0x16): undefined reference to `OutputDebugString'
 collect2: ld returned 1 exit status
 hbmk: Error: Running linker. 1
 gcc demoqt.o hbmk_7jn45m.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
 -lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
 -Wl,--end-group -odemoqt -L/usr/lib/harbour
 

I just left Windows specif code, please commentout these two functions.
I will fix it in a while.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-on-linux-tp23950406p23950497.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt on linux


Pritpal Bedi napsal(a):

Hi

Welcome onboard.


siki-2 wrote:
  

Hello

I try to make demoqt  on linux (Ubuntu 9.04)

after coment out  #include windows.h at line 727 I got:

demoqt.o: In function `HB_FUN_UIDEBUG':
demoqt.c:(.text+0x16): undefined reference to `OutputDebugString'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc demoqt.o hbmk_7jn45m.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
-lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
-Wl,--end-group -odemoqt -L/usr/lib/harbour





I just left Windows specif code, please commentout these two functions.
I will fix it in a while.

Regards
Pritpal Bedi

  

Sorry to bother but take a look to this:

s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ ./demoqt
Object::connect: No such signal QTreeView::hovered() in 
../../hbqt_slots.cpp:274
Object::connect: No such signal QListView::hovered() in 
../../hbqt_slots.cpp:274


Demo work on linux, great job :-)

best regards
Davor


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

Re: [Harbour] demoqt on linux


Hello 


siki-2 wrote:
 
 Pritpal Bedi napsal(a):
 Thank You, I'm here from begin :-)
 but long time i using clip from www.itk.ru
 now porting all my application to harbour
 

Never saw you here so I thought..., poor me.



 what about  ?
 
 s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ hbmk2 wvtext.prg
 hbmk: Processing configuration: /usr/bin/hbmk.cfg
 hbmk: Processing: hbqt.hbc
 Harbour 2.0.0beta1 (Rev. 11288)
 Copyright (c) 1999-2009, http://www.harbour-project.org/
 Compiling 'wvtext.prg'...
 Lines 1209, Functions/Procedures 19
 Generating C source output to 'wvtext.c'... Done.
 wvtext.o:(.data+0x7a8): undefined reference to `HB_FUN_HB_GT_QTC_DEFAULT'
 wvtext.o:(.data+0x7b8): undefined reference to `HB_FUN_HB_GT_WVT_DEFAULT'
 wvtext.o:(.data+0x7c8): undefined reference to `HB_FUN_HB_GT_WIN'
 collect2: ld returned 1 exit status
 hbmk: Error: Running linker. 1
 gcc wvtext.o hbmk_h760kt.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
 -lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
 -Wl,--end-group -owvtext -L/usr/lib/harbour
 

Do not try to compile wvtext.prg on Linux.
It is meant for Windows only and is there for experiments.
Try demoqt.prg.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-on-linux-tp23950406p23950786.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt on linux


Pritpal Bedi napsal(a):

Hi

Welcome onboard.


  

Thank You, I'm here from begin :-)
but long time i using clip from www.itk.ru
now porting all my application to harbour

what about  ?

s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ hbmk2 wvtext.prg
hbmk: Processing configuration: /usr/bin/hbmk.cfg
hbmk: Processing: hbqt.hbc
Harbour 2.0.0beta1 (Rev. 11288)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'wvtext.prg'...
Lines 1209, Functions/Procedures 19
Generating C source output to 'wvtext.c'... Done.
wvtext.o:(.data+0x7a8): undefined reference to `HB_FUN_HB_GT_QTC_DEFAULT'
wvtext.o:(.data+0x7b8): undefined reference to `HB_FUN_HB_GT_WVT_DEFAULT'
wvtext.o:(.data+0x7c8): undefined reference to `HB_FUN_HB_GT_WIN'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc wvtext.o hbmk_h760kt.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
-lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
-Wl,--end-group -owvtext -L/usr/lib/harbour




siki-2 wrote:
  

Hello

I try to make demoqt  on linux (Ubuntu 9.04)

after coment out  #include windows.h at line 727 I got:

demoqt.o: In function `HB_FUN_UIDEBUG':
demoqt.c:(.text+0x16): undefined reference to `OutputDebugString'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc demoqt.o hbmk_7jn45m.o   -Wl,--start-group -lharbour -lgpm -lsupc++ 
-lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug 
-Wl,--end-group -odemoqt -L/usr/lib/harbour





I just left Windows specif code, please commentout these two functions.
I will fix it in a while.

  

yes I make it work ! :-)



Regards
Pritpal Bedi

  




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

Re: [Harbour] demoqt on linux

2009-06-09 Thread Viktor Szakáts


First question:

Why do we have 3 different copies of wvtext inside
our repo, when this demo is meant to demonstrate GTs,
and thus it should be the same for all GTs.

IMO we should delete wvtext from hbqt/tests (and
probably also from gtqtc/tests), but at least
remove all GTWVG, GTQTC and also GTWVT references
from the hbqt one, it's wrong. With hbmk2 it's
easy to select GT at build time, no need to hard-wire
it in source.

What do you think Pritpal?

Brgds,
Viktor

On 2009.06.09., at 22:26, siki wrote:


Pritpal Bedi napsal(a):

Hi

Welcome onboard.




Thank You, I'm here from begin :-)
but long time i using clip from www.itk.ru
now porting all my application to harbour

what about  ?

s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ hbmk2 wvtext.prg
hbmk: Processing configuration: /usr/bin/hbmk.cfg
hbmk: Processing: hbqt.hbc
Harbour 2.0.0beta1 (Rev. 11288)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 'wvtext.prg'...
Lines 1209, Functions/Procedures 19
Generating C source output to 'wvtext.c'... Done.
wvtext.o:(.data+0x7a8): undefined reference to  
`HB_FUN_HB_GT_QTC_DEFAULT'
wvtext.o:(.data+0x7b8): undefined reference to  
`HB_FUN_HB_GT_WVT_DEFAULT'

wvtext.o:(.data+0x7c8): undefined reference to `HB_FUN_HB_GT_WIN'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc wvtext.o hbmk_h760kt.o   -Wl,--start-group -lharbour -lgpm -lsupc 
++ -lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr -lhbdebug  
-Wl,--end-group -owvtext -L/usr/lib/harbour




siki-2 wrote:


Hello

I try to make demoqt  on linux (Ubuntu 9.04)

after coment out  #include windows.h at line 727 I got:

demoqt.o: In function `HB_FUN_UIDEBUG':
demoqt.c:(.text+0x16): undefined reference to `OutputDebugString'
collect2: ld returned 1 exit status
hbmk: Error: Running linker. 1
gcc demoqt.o hbmk_7jn45m.o   -Wl,--start-group -lharbour -lgpm - 
lsupc++ -lhbqt -lQtCore -lQtGui -lQtNetwork -lQtWebKit -lhbcplr - 
lhbdebug -Wl,--end-group -odemoqt -L/usr/lib/harbour





I just left Windows specif code, please commentout these two  
functions.

I will fix it in a while.



yes I make it work ! :-)



Regards
Pritpal Bedi






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


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

Re: [Harbour] demoqt on linux


Hi


siki-2 wrote:
 
 Sorry to bother but take a look to this:
 
 s...@siki:/opt/clipp/harbour/contrib/hbqt/tests$ ./demoqt
 Object::connect: No such signal QTreeView::hovered() in 
 ../../hbqt_slots.cpp:274
 Object::connect: No such signal QListView::hovered() in 
 ../../hbqt_slots.cpp:274
 
 Demo work on linux, great job :-)
 

I could never see these messages.
Thanks for the info. Will fix in a while.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-on-linux-tp23950406p23950821.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt on linux


Hi


Viktor Szakáts wrote:
 
 Why do we have 3 different copies of wvtext inside
 our repo, when this demo is meant to demonstrate GTs,
 and thus it should be the same for all GTs.
 
 IMO we should delete wvtext from hbqt/tests (and
 probably also from gtqtc/tests), but at least
 remove all GTWVG, GTQTC and also GTWVT references
 from the hbqt one, it's wrong. With hbmk2 it's
 easy to select GT at build time, no need to hard-wire
 it in source.
 
 What do you think Pritpal?
 

In hbqt, wvtext.prg got uploaded by chance, I think.
It has to be deleted from here and gtqtc also, no problems.
I was just experimenting.

If you do not do sonn I will do few hours later.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://www.nabble.com/demoqt-on-linux-tp23950406p23950851.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

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

Re: [Harbour] demoqt on linux