> pObj = ( QPointer< QPageSetupDialog > * )
> memset( hb_gcAllocate( sizeof( QPointer< QPageSetupDialog > ),
> &s_gcQPageSetupDialog ),
> 0, sizeof( QPointer< QPageSetupDialog > ) );
It is already "included" it is visually differ
I'm about to implement a -massivedebug switch to the generator
sample:
HB_FUNC( QT_QPUSHBUTTON_ISFLAT )
{
QPushButton * p;
HB_TRACE( HB, ( "Entering function QT_QPUSHBUTTON_ISFLAT" ) );
and with a bit more knowledge on parameters/object (also thanks to
Viktor generator2) we may also
Pritpal, I now think that in prg classes we should add destructor and
destroy all the children at harbour level from there, so doing that
ourself and not leaving the job to Qt
The other test I want to do is to use object.deleteLater() but it is
not a "solution", is an hack
___
On Thu, 15 Apr 2010, francesco perillo wrote:
Hi,
> Pritpal, I now think that in prg classes we should add destructor and
> destroy all the children at harbour level from there, so doing that
> ourself and not leaving the job to Qt
You may need explicit destructors in .prg code only if you
Hi Pritpal,
> For now I am including above patch in my tests.
> And if it resolves crashes with the updated code, I will commit.
> Later we will be waiting for Przemek's commit to see it the same
> is done on GC levels.
OK, sounds good. In any case if it fits to our needs is better than nothing
>
> Did you test this code ? I think, yes.
> Then prg level :addItem() method is missing, how you solved that?
> Manually writing in TQLayout.prg ?
I have this function in TQLayout.prg
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbo
Hi Pritpal,
> Did you test this code ? I think, yes.
Yes, you are right, and the crash is gone on my Fedora12.
> Then prg level :addItem() method is missing, how you solved that?
> Manually writing in TQLayout.prg ?
I replaced just QLayout.cpp.
Best regards,
István
__
Hi to everybody,
I tried to solve the problem starting from the end, the delete... I
wanted to intercept the delete and from the pointer going back to the
harbour QGC_POINTER and "nullify" it From the end you cover all
cases in a generic way..
Your solution is from another point of view, you
Hi Francesco,
> More, we need to devise a standard way to generate such code from
> qth/include files from the actual generator I think it is very
> difficult, we should create an in-memory structure of calls and then
> generate code as automatically as possible...
Yes, you are right, this p
> Yes, you are right, this patch is just the first step in the crash hunting.
> The next steps should be oriented to a more general dynamic approach.
This is an important patch because it started a new way for solving GPF...
Now there are several protections against GPFs...
- guarded pointers fo
Istvan,
in hbide.prg please comment all the :destroy() lines, there are a
bunch together... I will try later...
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo
Hi Francesco,
> in hbide.prg please comment all the :destroy() lines, there are a
> bunch together... I will try later...
I don't touched hbide.prg ???
Best regards,
István
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-projec
Hi,
>> BTW, after applying all your patches and cleaning hbXBP and hbIDE
>> code, where few objects were hanging around and few were wrongly
>> implemented, I can now get two RTEs ( yes, it is strange but true, 2 RTEs
>> )
>> at the very end of hbIDE exit :
>> Error BASE/1301 Object destructor
Istvan,
in hbide.prg Pritpal implemented a "controlled" destroy of objects. He
tried to sequence the destroy to release the children objects first...
Disabling this long list of :destroy() and implementing your changes
for all the cases where necessary, we should get a working program
with no GPFs.
Sorry Pritpal, you were correct.
In the QLayout.qth file proposed by Istvan the line of addItem is
commented and so the harbour class is not generated...
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://
A bit more tracing in the debug log
diff -r 020effeac192 harbour/contrib/hbqt/generatorF/hbqtgen.prg
--- a/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
09:56:57 2010 +0200
+++ b/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
22:52:42 2010 +0200
@@ -50,6 +50,8 @@
Francesco,
> Since I'm trying to implement your changes in the generator, if you
> have a better version please send...
My post doesn't contain any other info. I am happy if you can find the
solution in the generator part.
István
___
Harbour mailing
Since I got GPF in another point (removing the :destroy() part) of the
code (releasing a QToolBar) I used the trace above to see what
function calls were done on that QToolBar... they are
addAction
toggleViewAction
setIcon
at least one of them must have the change you proposed
Francesco
_
> Since I got GPF in another point (removing the :destroy() part) of the
> code (releasing a QToolBar) I used the trace above to see what
> function calls were done on that QToolBar... they are
> addAction
> toggleViewAction
> setIcon
> at least one of them must have the change you proposed
M
Ok, just for trying to understand how it is possible to proceed and to
validate the idea I did some tests... I was able to remove a GPFs
changing some add* functions.
It was a manual work and I strongly believe it can't be done manually !
Just for reference I post here one of this changed function
20 matches
Mail list logo
