Re: [Harbour] Re: Patch for Pritpal
Hi Francesco The whole point is, if we go this direction, I am afraid a lot of .qth have to be changed. Everywhere there is a parent/child relation. If this is required to fix HBQT, it should IMO be done eventually. It's not an argument against fixing things that it takes many source code changes IMO... Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Patch for Pritpal
The whole point is, if we go this direction, I am afraid a lot of .qth have to be changed. With my hbqtgen patch there is no need to change .qth files, just to write the specific new functions (that may be automatically generated once we set the necessary info somewhere) Everywhere there is a parent/child relation. Exactly - it should be done when an object becomes owned and we should also think about what to do when the object is un-owned... Probably I do not feel comfortable this way. May I ask why ? It's just a bad sensation or are there more technical reasons ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Patch for Pritpal
A couple more... QTableWidget_setVerticalHeaderItem Description: Binary data QTableWidget_setHorizontalHeaderItem Description: Binary data ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Patch for Pritpal
francesco perillo wrote:
PS: why didn't you use my patch to have the exceptional functions
out of qth files ?
Because we are not to deal with a whole new set of files which
may go unmanageable in the long run.
Also we agreed that this mechanism will be usedonly where we have
problem with the destruction mecanism.
I wanted to create a QTableWidget and populate it with different values.
My code is:
for i:= 1 to len(aL)
aAdd( oGridItem0x0 , )
t := QTableWidgetItem():new()
t:setBackground( oBrushBackItem0x0 )
t:setForeground( oBrushForeItem0x0 )
t:setText( cella +str(i) )
oGrid:setItem( i-1, 0, t )
next
The result was that only the last cell has value... this happens
because when t is re:New()ed, the previous t is destroyed ... so
::setItem needs treatment for detaching it when calling setItem
So please apply this patch:
HB_FUNC( QT_QTABLEWIDGET_SETITEM )
{
QGC_POINTER_QTableWidget * q;
QGC_POINTER * p;
HB_TRACE( HB_TR_DEBUG, (Entering QTABLEWIDGET_SETITEM ) );
q = ( QGC_POINTER_QTableWidget * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 4 );
if( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QTABLEWIDGET_SETITEM() Qt oject: %p
is attached to: %p, ( void * ) p-ph, ( void * ) q-ph ) );
p-bNew = HB_FALSE;
( q-ph )-setItem( hb_parni( 2 ), hb_parni( 3 ), (
QTableWidgetItem * ) p-ph );
}
}
Local aItems := {}
for i:= 1 to len(aL)
aAdd( oGridItem0x0 , )
t := QTableWidgetItem():new()
t:setBackground( oBrushBackItem0x0 )
t:setForeground( oBrushForeItem0x0 )
t:setText( cella +str(i) )
oGrid:setItem( i-1, 0, t )
aadd( aItems, t )
next
// And destructor
for each aItm in aItems
qItm := NIL
next
This mechanism has an advantage.
You have all the control over items spread in different columns,
and can later deal with them if there is a need of changes, for example,
if you would like to let it be edited or changing the colors.
This is how it looks close to Clipper syntax.
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://harbour-devel.1590103.n2.nabble.com/Patch-for-Pritpal-tp4977113p4977369.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Patch for Pritpal
Also we agreed that this mechanism will be usedonly where we have
problem with the destruction mecanism.
not really. this mechanism must be used when a object becomes owned by
some other object to avoid a double destruction...
Probably I should go directly to xbp (I see you wrote tons of code
lines for the browse system) strictly following the published code and
try to never read the source code because I fear that there are some
hacks to overcome some hbqt problems... :-)
Local aItems := {}
cut
this was the first test I did in order to check that no other problems
were present... and it worked.
But I feel it is not a correct way... since there is no need to store
them from a functional point of view i
// And destructor
for each aItm in aItems
qItm := NIL
next
This mechanism has an advantage.
You have all the control over items spread in different columns,
and can later deal with them if there is a need of changes, for example,
if you would like to let it be edited or changing the colors.
I can do this using ::item(row,col) if necessary
This is how it looks close to Clipper syntax.
But not to c++ samples...
More, some other patches should be done, for example for
QTableWidget::setCellWidget... please read the doc text...
There another probable problem if the patches are not committed... if
you have not compiled my patches try my unmodified sample but change
only:
oGrid:setItem( i-1, 0, t )
to
oGrid:setItem( 0, 0, t ) // all items set at the same place
does it GPF ? with setCellWidget it will according to the doc text
Ciao,
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Patch for Pritpal
Hi Francesco The whole point is, if we go this direction, I am afraid a lot of .qth have to be changed. Everywhere there is a parent/child relation. Probably I do not feel comfortable this way. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Patch-for-Pritpal-tp4977113p4977471.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Patch for Pritpal
Hi Consider this scenario: If this approach be taken, then it becomes impossible to release the memory occupied by those QTableWidgetItems any way until application is closed. Suppose in between you are to clear the table many times and need to reuse it, application will constinue to consume memory. We used this mechanism where we had a problem to to freeing the memory. In QTabelWidgetItem/QTreeWidgetItem, etc., where nodes can be in abundance, this is not appropriate. Hope my point will be clean by now. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Patch-for-Pritpal-tp4977113p4977513.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Patch for Pritpal
Pritpal Bedi wrote: Consider this scenario: If this approach be taken, then it becomes impossible to release the memory occupied by those QTableWidgetItems any way until application is closed. Suppose in between you are to clear the table many times and need to reuse it, application will constinue to consume memory. We used this mechanism where we had a problem to to freeing the memory. In QTabelWidgetItem/QTreeWidgetItem, etc., where nodes can be in abundance, this is not appropriate. Hope my point will be clean by now. I think my above statement is _WRONG_. Please ignore it. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/Patch-for-Pritpal-tp4977113p4977544.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
