Unrecoverable error 6005: Exception error: Exception Code:C0000005 ACCESS_VIOLATION

[Zoran Sibinovic]

Hi to all,

time ago I started this problem.

I thought that maybe it was solved whit the latest revisions due to how the classes are handled but, the problem still appears.

For those  who are not familiar with the problem I will explain it again.

I use Windows no matter the version, the issue is the same, and appears on different computers also.

With the 5.6.0 version of Qt, every dialog created with oDlg := hbqtui_...() cause the app termination with the described errors in the logs attached to this post.

The app that can be used for the test is composite.prg from the tests folder

The issue can be provoked  by opening and closing the "Customer info" menu item. The number of open/close times, till the termination succeded is random, sometimes 5-6 sometimes more, but everytime terminates with the crash of the entire app.

The Qt 5.5.1 version is the latest with which everything works normal.

I read the What's new about the Qt 5.6 version at: 

https://doc.qt.io/qt-5/whatsnew56.html#:~:text=Improved%20cross%2Dplatform%20OpenGL%20ES,with%2016bits%2Dper%2Dcolor.

and seen that they changed something about the memory usage, the GUI, etc.  

This is my environment sets for Qt 5.6.3:

SETX -m HB_QT_MAJOR_VER "5"
SETX -m HB_QT_MINOR_VER "5"
SETX -m HB_INSTALL_PREFIX "c:\hb"

SETX -m MGWHOME     "c:\Qt\Qt5.6.3\Tools\mingw492_32"
SETX -m MGWBIN      "c:\Qt\Qt5.6.3\Tools\mingw492_32\bin"

SETX -m QTHOME      "c:\Qt\Qt5.6.3\5.6.3\mingw49_32"
SETX -m HB_QTPATH   "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\bin"
SETX -m HB_WITH_QT  "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\include"
SETX -m QTPLATFORMS "c:\Qt\Qt5.6.3\5.6.3\mingw49_32\plugins\platforms"

REM c:\hb
REM c:\hb\bin\win\mingw
REM %MGWHOME%
REM %MGWBIN%
REM %QTHOME%
REM %HB_QTPATH%
REM %HB_WITH_QT%
REM %QTPLATFORMS%
REM - added directly in OS environment parameters PATH 

So did I missed something?

Thanks for every answer.

Zoran

[Pritpal Bedi]

Hi Zoran

I never recommended 5.6. Use either 5.5 or 5.8 where I do not see any crash.

Pritpal Bedi

a student of software analysis & concepts

[Zoran Sibinovic]

Hi Pritpal,

thank you for this tip I didn't know about this.

One thing more, did I have to add some additional environvent parameters to mine above descripted to make work the 5.8 version and that are not been required for the 5.5 version?

Thank you again

Zoran

[Zoran Sibinovic]

Hi Pritpal,

I compiled harbour and Qtcontribs with Qt 5.8.0 with this environment parameters ...

SETX -m HB_INSTALL_PREFIX "c:\hb"

REM /*----------------------------------------------------------------*/
REM ....... Qt settings
REM /*----------------------------------------------------------------*/

SETX -m QTROOT       "c:\Qt\Qt5.8.0"
SETX -m QTHOME      "c:\Qt\Qt5.8.0\5.8\mingw53_32"
SETX -m QTBIN           "c:\Qt\Qt5.8.0\5.8\mingw53_32\bin"
SETX -m QTINC           "c:\Qt\Qt5.8.0\5.8\mingw53_32\include"

REM /*----------------------------------------------------------------*/
REM ....... MINGW
REM /*----------------------------------------------------------------*/

SETX -m MGWHOME     "c:\Qt\Qt5.8.0\Tools\mingw530_32"
SETX -m MGWBIN          "c:\Qt\Qt5.8.0\Tools\mingw530_32\bin"

REM /*----------------------------------------------------------------*/
REM ....... required
REM /*----------------------------------------------------------------*/

SETX -m HB_WITH_QT      "c:\Qt\Qt5.8.0\5.8\mingw53_32\include"
SETX -m HB_QTPATH       "c:\Qt\Qt5.8.0\5.8\mingw53_32\bin"
SETX -m HB_QT_MAJOR_VER "5"
SETX -m HB_QT_MINOR_VER "8"
SETX -m HB_USER_CFLAGS  "-std=gnu++11"

SETX -m QTPLATFORMS     "c:\Qt\Qt5.8.0\5.8\mingw53_32\plugins\platforms"

REM c:\hb; c:\hb\bin\win\mingw; %MGWHOME%; %MGWBIN%; %QTHOME%;  %HB_QTPATH%; %HB_WITH_QT%; %QTPLATFORMS% (directly added in OS environment parameters PATH) 

... and still got the hb_out in the attachment after open/close "Customer info" in composite.exe ...

this happened after at the 7-th consecutive dialog opening ... but it is a random opening number

I really don't understand what I'm doing wrong.

Thanks

Zoran

[Pritpal Bedi]

Hi Zoran

I could reproduce the error - after 17 iterations it booms. Will see what can be done to handle such situations.

Pritpal Bedi

a student of software analysis & concepts

[alex;]

Hi, Zoran.
I  reproduce the error on version 5.15.2 on Windows 10.
How to find log in my system?
Are you still using 5.5.1?

WBR, alex;

вторник, 23 мая 2023 г. в 12:23:50 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Hi Alex,

I stayed at the 5.5.1 version till today.

I tried for several times various newer versions and their updates but without any success.

Sorry

Zoran

[alex;]

I think AI can help solve this problem.
I'll have to try it later.

WBR, alex;

понедельник, 25 ноября 2024 г. в 11:10:07 UTC+3, Zoran Sibinovic:

[alex;]

Hi, Zoran.
I'm on vacation. ))

I added next code in hbqt_bind.cpp

-------------------

#include <QtCore/QFile>
#include <QtCore/QTextStream>

...

int __hbqt_bindItemsInGlobalList( void )
{
   QFile logFile("output.log");
   logFile.open(QIODevice::WriteOnly | QIODevice::Append);
   QTextStream stream(&logFile);

   stream << "Begin" << Qt::endl;

...

stream << "_____Items #" << i << "______(" << bind->szClassName << ")" << Qt::endl;

...

 logFile.close();

-------------------

and got next results:

1. on init

Begin
_____Items #1______(HB_QEVENTLOOP)
_____Items #2______(HB_QACTION)
_____Items #3______(HB_QWIDGET)
_____Items #4______(HB_QMAINWINDOW)
_____Items #5______(HB_QFONT)
2. after close second dialog

_____Items #1______(HB_HBQPROXYSTYLE)
_____Items #2______(HB_QEVENTLOOP)
_____Items #3______(HB_QACTION)
_____Items #4______(HB_QWIDGET)
_____Items #5______(HB_QMAINWINDOW)
_____Items #6______(HB_QFONT)

I see that added HB_HBQPROXYSTYLE

what is it?

what do you think?

WBR, alex;

понедельник, 25 ноября 2024 г. в 11:10:07 UTC+3, Zoran Sibinovic:

Hi Alex,

[Zoran Sibinovic]

Hi Alex, I don't know either. I found in https://doc.qt.io/qt-6/qproxystyle.html that is something that regards the displyed style. Sorry if it can't help you

--
You received this message because you are subscribed to a topic in the Google Groups "QtContribs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qtcontribs/wSWZGBGdicw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qtcontribs+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/aaab32d1-7d2f-420c-8a20-20e1a545b980n%40googlegroups.com.

[alex;]

Hi, Zoran. I've posted some ideas here. https://groups.google.com/g/harbour-users/c/3dFu8qu7iUM

среда, 14 мая 2025 г. в 08:22:41 UTC+3, Zoran Sibinovic:

[Francesco Perillo]

Please follow my reasoning.

hbqtui_* functions are included in .prg files created on the fly during the compilation process.

If you open one of these generated files you will see that follow the same skeleton and we are interested in the destroy() method.

METHOD ui_hbpdbstruct:destroy()
   ::groupBox                          := NIL
   ::label                             := NIL
   ::editName                          := NIL
   ::label_2                           := NIL
   ::comboType                         := NIL
 

I ask you to retrieve the generated .prg file of the form you have problems with, copy it in your main directory and in the .hbp change the reference from the .ui file to this .prg.

In this way you are compiling a source file like many other but you can make changes AND ADD TRACING LOGS!

As you can see  the first item to be destroyed is the groupBox, the container ! Qt should recursively destroy all the children items but it may do it in a different order in different Qt versions and this may create the problem !

If I were in your place, I'd change the code to:

METHOD ui_hbpdbstruct:destroy()

log ("before groupbox")

   ::groupBox                          := NIL

log ("before label")

   ::label                             := NIL

log ("before editname")

   ::editName                          := NIL

trying to locate the exact moment  the fault appears.

I also have mixed feelings about

  ::oWidget                           :setParent( QWidget() )
   ::oWidget                           := NIL

 

It has been a long time since I had a look at hbqt internals and may have wrong memories.

I'd work on this file commenting all the code of the destroy() method.

You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/ef2841b4-b291-4527-a918-960ce76b4da6n%40googlegroups.com.

[alex;]

Hi, Francesco.
It seems to me that the objects are being destroyed, but the references in the HBQT_BIND structure are not being deleted.
WBR, alex;

суббота, 17 мая 2025 г. в 11:28:19 UTC+3, Francesco Perillo:

[Francesco Perillo]

When a widget is created by the hbQt layer, we register a sort of callback when the Qt object is about to be deleted.

A lot of man hours were used to create a system that can resist to unexpected order of object destruction, both when solicited from c++ or HbQt.

I haven't seen your code. You reported the following log lines, with HBQProxyStyle not deleted... this object is not handled by the automatic deletion of the objects.

It is used twice in hbQt code, one is in hbqt\tests\demoqt.prg. Can you please try this demo ? I tested it with qt 5.5 and it works.

It is also used in the alternative getsys system. but I didn't test it.

Are you using HBQProxyStyle ? Are you using the getsys included in hbQt ?

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/e655ef52-295c-47c9-8dc7-467b4635b593n%40googlegroups.com.

[Luigi Ferraris]

Hi Alex

As @Francesco writes, adding my little experience

::oWidget:setParent( QWidget() )

You can also use ::oWidget:setParent(0) to detachs object from its parent at Qt level

and than ::oWidget := NIL, but sometime is not enough.

The objects you see in your log, AFAIK are UNdestructed objects IOW already alive from HbQt (.PRG) perspective.

Regards

Luigi

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr8%3Dw0wxk3D%3Dt6z88_KznkNGcAR9gagsy6nsFvJNcmHRWg%40mail.gmail.com.

--

Luigi Ferraris
www.l3w.it

[Francesco Perillo]

I read again the thread and found the reference to the composite.prg demo. Unfortunately I only have Qt 5.5.0 installed so I can't try with new versions.

The demo - as its name implies - mix standard Qt widgets created by the hbqtui_composite() functions, other hbQt objects added at runtime and, more important, objects related with the GET system created by Pritpal.

The outcome is the following:

When I first start the demo I see in the title bar that there are 5 objects created. Open the menu, 101 objects, close the form, 6 objects..... probably that HBQPROXYSTYLE. Open the form again: 100 objects... why one less ? 6 100 6 100 6 100 the values don't change anymore.

With this new knowledge I'd start debugging removing any reference to HBQPROXYSTYLE from hbqtwidgets\getsys.prg It is used only for cursor width (insert vs replace editing)

If the problem persists, it is not HBQPROXYSTYLE fault and we should explore other ways to find the bug.

[alex;]

Francesco,  you're right. I was thinking of moving in that direction too. I think QPROXYSTYLE was added to use an alternative style. For example, the gradient for the Qlabel in composite.prg.

WBR, alex;

воскресенье, 18 мая 2025 г. в 14:18:36 UTC+3, Francesco Perillo:

[Zoran Sibinovic]

Hi, It's an old problem topic that I started. Till now you can use at last the 5.5.1 version without this issue. All the newer versions produce this error. Till now the solution is not founded.

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/f020e3ae-9549-4ee6-96e3-1c2fd268c412n%40googlegroups.com.

[alex;]

In addition,
I have entered
!analyze -v
in WinDbg and returned the results of the crash analysis to Copilot.

The call stack shows that the call goes through QAbstractButton::isCheckable, then QStyleHelper::isInstanceOf, and then through QWindowsVistaStyle::DrawPrimitive.

So yes, I think the problem is with the styles.

WBR, alex;

воскресенье, 18 мая 2025 г. в 14:32:23 UTC+3, Zoran Sibinovic:

[alex;]

Copilot again:
That's the key problem! If ::style:parent() is NIL, then Qt does not manage the lifetime of HBQProxyStyle, and it remains in memory after the form is closed. In Qt, QObjects that do not have a parent are not deleted automatically, they need to be deleted manually.

воскресенье, 18 мая 2025 г. в 14:39:26 UTC+3, alex;:

[Francesco Perillo]

Ok, I see a little difference between the code generated code of QLabel and HBQProxyStyle

   hb_itemReturnRelease( hbqt_bindGetHbObject( NULL, pObj, "HB_QLABEL", hbqt_del_QLabel, HBQT_BIT_NONE | HBQT_BIT_OWNER | HBQT_BIT_QOBJECT ) );

   hb_itemReturnRelease( hbqt_bindGetHbObject( NULL, pObj, "HB_HBQPROXYSTYLE", hbqt_del_HBQProxyStyle, HBQT_BIT_NONE | HBQT_BIT_OWNER ) );

Looking at hbqt\qtcore\hbqt_init.cpp this missing flag may explain the missing DELETE.

QProxyStyle is derived from a QObject as we may clearly see here: https://doc.qt.io/qt-6/qproxystyle-members.html

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/a73b5d97-6680-439e-90a6-b33554b3ff2bn%40googlegroups.com.

[Francesco Perillo]

I can't understand why Qt should call DrawPrimitive when closing the application !!!???

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/d9deb114-7935-4ea5-82ee-286597f641den%40googlegroups.com.

[alex;]

If click on buttons and them to close dialog, then will be 30 active objects.

воскресенье, 18 мая 2025 г. в 15:52:23 UTC+3, Francesco Perillo:

[Luigi Ferraris]

I believe HbQt suffers from two problems:
   1) that Qt is constantly changing and
   2) the desire to use Qt with Harbour as soon as possible.
   
AFAIK there are 3 great family of Qt objects:
   a) not derived from QObject
   b) derived from QObject
   c) derived from QWidget
   
From my POV, each of these needs to have its counterpart in the HbQt world.

If you write a C++ class and it contains e.g. m_icon = QIcon, you need to "manualy" delete

m_icon otherwise memory leak occurs.

Next are only simple code to explain my bad English

So, 1st HbQt class may be
CLASS HbQtAnyHandler
   ACCESS pointer                               INLINE ::pPtr
   METHOD HbClean
METHOD hbClean() CLASS HbQtAnyHandler
   // do something at CLipper level
RETURN self

2nd HbQt class (+- like current) QObject derived
CLASS HbQtObjectHandler INHERIT hbQtAnyHandler

3d HbQt class QWidget derived
CLASS HbQtWidgetHandler INHERIT HbQtObjectHandler

As you can see, the HbClean method can be used to place your code as
   ::m_icon1 := NIL
   ::m_translator := NIL
   in any CLipper class/object
   
Other big problem (a lot of thread exist): iheritance, Qt parent/child chain, Clipper var out of scope
If you write your own class myWidget with additional methods (and vars), than code
   LOCAL window, dummy
   window := QMainWindow()
   window:setCentralWidget( myWidget( window ) )
   dummy := window:centralWidget()
Probably, you get back an object with class "QWidget" instead of "myWidget".

So you need to code
   LOCAL window, m_central
   window := QMainWindow()
   m_central := myWidget( window ) N.B. but now you have a CLipper var/object alive
   window:setCentralWidget( m_central )
   dummy := window:centralWidget() <== so it's unuseful because you have m_central
in many circumstances (expecially in your project classes) you must code
   m_central := NIL where?

and if you code
   LOCAL window, m_central, dummy
   window := QMainWindow()
   m_central := myWidget( window )
   window:setCentralWidget( m_central )
   m_central := NIL
   dummy := window:centralWidget() what you get?
   

Third an last AFAIK we cannot "emit signals" and sometimes is or may be usefull.

I don't have a good skill or a good knowledge of C/C++ in Harbour and Qt otherwise I would try to implement it

So, your problem (probably) is due to missing code as Francesco writes but take in account these warnings

Regards

Luigi

[alex;]

Hi.
So, simple, needed an extended class and object registrar in test mode and HB_TRACE_ALTER wtih GUI, f.e. based on sqlite.
Let's do it.

;o)

WBR, alex;

понедельник, 19 мая 2025 г. в 18:12:46 UTC+3, Luigi Ferraris:

[alex;]

Step by step...
Shiboken doc:
By default the ownership of an object created in Python is tied
             to the Python name pointing to it. In order for the underlying
             C++ object not to get deleted when the Python name goes out of
             scope, we have to transfer ownership to C++.

[alex;]

The problem is almost certainly caused by incorrect lifecycle management of Qt widgets in qtcontribs: `HbQtGetList` contains `CLASSVAR oFocusFrame INIT QFocusFrame()`, i.e. one singleton `QFocusFrame` is reused between all dialogs, and after closing the window the code does not destroy the widgets, but only does `setParent( QWidget() )`, creating an orphan widget tree; As a result, the Qt style/accessibility subsystem (`QAccessibleGroupBox`, `QWindowsVistaStyle`, `HBProxyStyle`) keeps stale pointers to already destroyed parent trees, which leads to a use-after-free/access violation when reopening the dialog, while the remaining `HBProxyStyle` object in `__hbqt_itemsInGlobalList()` is a strong indicator that the style engine is keeping alive incorrectly detached/shared widgets.

вторник, 13 января 2026 г. в 00:40:34 UTC+3, alex;:

[alex;]

Correctly deleting `HbQtGetList` is not just zeroing the array and unbinding the parent, but correctly breaking all Qt-ownership: first, remove the focus frame and all associated QWidgets (including `oFocusFrame`) via `hide()` + `deleteLater()`, then iterate over `aGetList` and call `destroy()`/`deleteLater()` for each `HbQtGet`, after which clear `HbQtBindGetList` (remove the entry for `oWnd` and call cleanup to destroy `oGetList` and its `oFocusFrame`), then be sure to reset `__hbqtGetsActiveWindow()` and only after that unbind `oWnd` via `setParent( NIL )` or let Qt close it itself via `close()`; The key idea is not to use `setParent( QWidget() )` as “deletion”, but to bring the object to real Qt-destruction via `deleteLater()`, otherwise living `QObject/QWidget` will remain in global lists and the style engine will work with already destroyed trees, which is what your AV gives.

понедельник, 11 мая 2026 г. в 14:48:07 UTC+3, alex;:

[alex;]

In the HbQtClearGets function (or __hbqtBindGetList when called with the oWnd parameter and NIL), after retrieving oGetList from the global list, you must explicitly call oGetList:destroy() (having previously implemented this method in the HbQtGetList class, which will destroy all HbQtGet objects, set the ::oFocusFrame parent to NIL and call deleteLater() for ::oFocusFrame), since the current code only zeroes out the local variable, leaving the classvar QFocusFrame() alive with dangling references to the destroyed widgets.

понедельник, 11 мая 2026 г. в 14:50:42 UTC+3, alex;:

[alex;]

Hello, to All. I used 4 LLMs to help. It's working now.
https://chat.qwen.ai/s/ba23a62a-4778-4505-8e4a-3e7c737382eb?fev=0.2.57

I had to change hbqt_bind.cpp I have attached it. But this is not the final option.
The fixes resolve critical use-after-free crashes and persistent object leaks in the Harbour-Qt binding layer by properly synchronizing Harbour's explicit destruction calls with Qt's event-driven object lifecycle. Previously, bind entries lingered in the global lookup table long after objects were destroyed, causing dangling-pointer crashes during UI repaints and preventing accurate resource tracking. The solution introduces a `fPendingDelete` flag to safely defer Qt deletions via `deleteLater()`, immediately purges bind records from the global list upon explicit destruction, removes unsafe manual `disconnect()` calls that interfered with Qt's internal teardown, and ensures critical metadata is copied before memory deallocation, resulting in stable, leak-free object management across repeated dialog open/close cycles. WBR, alex.

понедельник, 11 мая 2026 г. в 14:52:57 UTC+3, alex;:

[Francesco Perillo]

Hi Alex,

have you tried to change

   CLASSVAR oFocusFrame                           INIT QFocusFrame()

to

   DATA oFocusFrame                           INIT QFocusFrame()

and the same in getsys.prg, with the old hbqt_bind of course.

I fear that CLASSVAR keeps the harbour object active

I remember that I experimented using QSS styles to change how a widget appears when in error or when it has focus. I remember to experiment with QSS classes or tags.

[alex;]

Hello, Francesco.
I've tried doing DATA, it works too.
If you make mistakes, show me.
Maybe we can figure it out together.

P.S. How is Pritpal doing?

понедельник, 25 мая 2026 г. в 00:42:22 UTC+3, Francesco Perillo:

[Pritpal Bedi]

Hi Alex

I am very much here. Will look into your fix soon. Thanks.

Pritpal Bedi   a student of software analysis & concepts

http://www.vouch.in   Vouch, the software that GROWS with you

http://sourceforge.net/projects/qtcontribs   HbQt, Harbour bindindings for Qt

http://cacherdd.sourceforge.net   World's First True RDBMS Rdd for (x)Harbour 

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/865274d8-850d-4ed1-8800-9177d29a969dn%40googlegroups.com.

[Francesco Perillo]

Just to add some bits:

from QFocusFrame documentation:

Normally an application will not need to create its own QFocusFrame as QStyle will handle this detail for you. A style writer can optionally use a QFocusFrame to have a focus area outside of the widget's paintable geometry. In this way space need not be reserved for the widget to have focus but only set on a QWidget with QFocusFrame::setWidget. It is, however, legal to create your own QFocusFrame on a custom widget and set its geometry manually via QWidget::setGeometryhowever you will not get auto-placement when the focused widget changes size or placement.

I understand that QStyle can provide the same, and more, feature of QFocusFrame, that is actually used to draw a red border of the widget that has focus. And QStyle is already used to change the cursor width.

But for the red border I'd use QSS...

https://doc.qt.io/qt-6/stylesheet-reference.html

see the :focus specifier. I used another way, assigning a tag

Have a look here:

https://stackoverflow.com/questions/50845702/qt-change-stylesheet-on-focus-in-out-event

I'd also move the classvar to a STATIC variabile assigned during an INIT PROCEDURE, in this way you have a set and forget, completely independent Qt object.

Unfortunately I never used those classes and probably I will never will, it would be great if we could give this code some more love.

Francesco

PS: I'm not saying your proposed code is wrong, I say that since I don't know how a classvar actually works, it can keep references for too long.

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/865274d8-850d-4ed1-8800-9177d29a969dn%40googlegroups.com.

[alex;]

Francesco, this is really interesting. There are already two variables in getsys.prg
   CLASSVAR oStyle                                INIT HBQProxyStyle()
   CLASSVAR sl_font

I think we can discuss this in a separate topic.

WBR, alex;

вторник, 26 мая 2026 г. в 21:32:35 UTC+3, Francesco Perillo:

[Zoran Sibinovic]

Hi to all,

I've been absent in the past few months and now back.

From what I saw seems to me that the error is addressed  on  HbQtGetList,  QFocusFrame, their deletion etc.

I tried today on on the spot and with a fresh Qt 5.8.0 the CLASSVAR to DATA replacement only and, not only in hbqtwidgets, but in the whole addons folder.

I recompiled the composite example without changing anything in composite.ui:

1. I deleted everything related to the gets in the .prg. (obrowse and the other objects remain) - The objects, after exiting the dialog, rise by one (from 5 to 6) and stays on 6 till the app crash. 

2. I deleted  everything related  to the browse object (gets and the other objects remain)  -  The objects, after exiting the dialog, not increase (5 all the way) and later comes the crash.

3. I deleted everything related to the gets and the browse, (all the other objects remain) - There is no rise of the number of objects and the app does not crash 

so correct me If I am wrong ... I think that here, there are not one, but two situations/issues to fix and both seems to be related to the GET handling, taking in account that the browse system is also based on the GETs

In 1. we have except the problem with the object deletion on the dialog exit (that not must be one that is the crutial) and another "undercoverd" that crushes the app.

In 2. there are no tails that increase the objects number after exit the dialog but there is still  "something" else that crashed the app.

Based on that, seems that the increase of the object number maybe is not the main reason for the crash but the GET system handling itself. Unfortunately I cannot say what it can be at this moment.

Best regards Zoran

[Алексей Запольский]

Hello, Zoran.
You're wrong. The crash is related to the object deletion policy in Qt. hbqt_bind did not take this into account. Try to just replace hbqt_bind.cpp .

But the number of objects depends on the implementation of getsys.prg and getlist.prg.

WBR, alex;

пт, 29 мая 2026 г. в 13:41, Zoran Sibinovic <zoran.s...@gmail.com>:

You received this message because you are subscribed to a topic in the Google Groups "QtContribs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qtcontribs/wSWZGBGdicw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qtcontribs+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/6abf2e36-dc2b-415e-b1db-6dff88f4da1en%40googlegroups.com.

[alex;]

My apologies.
The AI ​​messed up the formatting. I've tried to fix it.
Now the key changes are visible when comparing. Attached.

WBR, alex;

пятница, 29 мая 2026 г. в 17:24:24 UTC+3, alex;:

[Pritpal Bedi]

Hi Alex

I tested your hbqt_bind.cpp and found that it blows up the app in few clicks. 
Try on hbqtwidget/tests/validator.hbp it will crash in few clicks on opening multiple modules.

NOTE: I only use Qt 5.5 or Qt 5.8 in static mode only so the results can differe from mine and yours.

BTW, I have never experienced any crash in my very large applications running in production environment with hundred of systems.

Pritpal Bedi
a student of software of software analysis and concepts.

[Pritpal Bedi]

BTW a stress test on tests - validator.hbp

I opened all 5 dialogs 20 times each and every time a window was close object-in-memory returned to 11.

When application starts the object count is 10. On first dialog it goes 22 or so. Returning after first dialog, object count is 11.
Then the count stays at 11 every time you close a window. The 11th object is QFocusFrame which is alway ONE for the entire duration of the application and is never destroy until app is exit()ed.

Pritpal Bedi

[alex;]

Hello, Pritpal.

Yes, everything works. Apparently, the patch needs to take the Qt version into account.

WBR, alex;

воскресенье, 31 мая 2026 г. в 00:02:42 UTC+3, Pritpal Bedi:

[Francesco Perillo]

Did you use the proposed hbqt_bind or the old one?

Which qt version?

There may have been some regressions in qt code

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/8b5b2665-6beb-49de-a832-97aef0a6196an%40googlegroups.com.

[Pritpal Bedi]

Alex

I used your cpp, compiled qtcore, linked validator.hbp, found validator crashing.

Already committed version is fine.

Pritpal Bedi   a student of software analysis & concepts

http://www.vouch.in   Vouch, the software that GROWS with you

http://sourceforge.net/projects/qtcontribs   HbQt, Harbour bindindings for Qt

http://cacherdd.sourceforge.net   World's First True RDBMS Rdd for (x)Harbour 

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr8M1pn2Vk%3D0a3H1WYoHz%3DFd0L2ROPY9o_-FpqQVpTEFOQ%40mail.gmail.com.

[Zoran Sibinovic]

Hi to all,

I have tried this morning the test apps with Qt 5.8.0 and the latest HbQt reviosion by Pritpal.

The composite.exe still crushes.

After replaced the hbqt_bind.cpp from Alex, composite.exe does not crush so far but ... validator.exe crashes on every option except the second (2.).

The dashbrd.exe crushes when you select the dialog for: new define browse object at its closure.

Also glossybutton.exe shows an error that I can relate to the Alex hbqt_bind.cpp or maybe it is?

I cannot verify the crush on the other tests because they have only one dialog. The crush happends when you call a new dialog from the main except now from composite. :)

Seems it depends from the way and the objects type created in the internal dialogs.

Also is needed to add, to compile some test apps , in hbmk.hbm

hbwin.hbc
hbct.hbc

Pics below

Zoran

[alex;]

понедельник, 1 июня 2026 г. в 10:50:03 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Yes,

that is the only option that dont crush the app after exit this dialog.

[kamlesh patel]

Hello.

How to make a harbour with qt compile.

Please explain.

Best Regards

Kamlesh

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/3585e8b3-3b9a-44b8-a2fe-de9efc89da41n%40googlegroups.com.

[Pritpal Bedi]

Hi Everybody

I confirm COMPOSITE.HBP shows regression. Dialog which host a browser, a highly comples GUI implementation, do not release of so Qt object and app crashes eventually after few open/closer of the dialog. 

This has been a known issue since begining so I had suggested to re-purpose such windows noy by closing but by hiding once craeted abd than shown when required.

I will try to find a solution, if any I could get.

Pritpal Bedi

a student of software analysis and concepts

[Zoran Sibinovic]

Hi to all,

Pritpal,

if you completely delete the browse object from composite.prg the app will  still crush because it still contains the gets object. If you omit also the gets, then the app will not crush. The other objects pass the test.

The increase of the object number for 1 after exit the dialog, is not a problem anymore, since it is intended to behave in that manner to be reused.

You can modify the browse but the get object remains to trigger the issue.

Yoran   

[Francesco Perillo]

So, is it possible to create the smallest program that crash in a repeteable, predictible way?

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/eafe3d48-24ca-4049-bbdf-f94aa1b12b88n%40googlegroups.com.

[Zoran Sibinovic]

Please for a confirmation of a non-crash:

Qt 5.8+ and qtcontribs r485

composite.exe

1. remove the listbox from composite.prg and composite.ui 

2. remove all except the listbox

I have done these tests and can't cause the crush.

Any other combination of objects cause it.

Thanks

[Zoran Sibinovic]

continue ... 

Like in composite.exe:

1. I can confirm that my apps crash only if i have a listbox in the used .ui. The ones that  does haven't it works ok, no matter the number of open/close iterations.

2. Tried validator.exe - It crashes on the 1., .3., 4. and 5. options 

Zoran

[Francesco Perillo]

During compilation, .ui is transformed in a .prg.

Please recover that prg and use it to make tests. In this way we can see how the listbox is created and remove the ui-》 prg conversion as a possible problem

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/21cc6cd7-763e-4b58-8447-7c277ecbf783n%40googlegroups.com.

[Francesco Perillo]

I strongly feel this is really casual.

Please use the generated uic_composite.prg (remove the .ui from the .hbp file and add the uic_composite.prg). Now shuffle the order of object creation and see if you can replicate the problem

I have 5.5.0 on this notebook, composite starts at 5 objects, when I open the form it reports 101 and if I close the form 5 becomes 6, and we know why.

If I use the browse, like click on the search button then press ESC, the program stops with an harbour error about missing objects/methods. Please note I'm on a version of hbqt dated february 15 2017 (r447) !!!!

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/21cc6cd7-763e-4b58-8447-7c277ecbf783n%40googlegroups.com.

[Zoran Sibinovic]

Try to switch to 5.5.1 and r484.  I use it with no peoblems 

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr_gsad7yo2SKFAztvQz6C5Kc%3DvBvMVAmKuL8BQP15RiEg%40mail.gmail.com.

[Francesco Perillo]

Hi Zoran,

give me 3 valid reasons I should install Qt 5.5.1.  :-))))

I give 3 I shouldn't:

1. 5.5.1 is a minor release, everything should work but who knows ?

2. the installer requires to have a Qt account and I'm not sure if I have one and sincerely .... ok, let's see, I may create an account...

3a. from what I understand the problems/crashes are with later Qt versions

3b. hbQt support drifted from old Qt versions to newer versions

I may consider to install a newer version if it can help debug the crashes.

Francesco

[Zoran Sibinovic]

No particulary reason at all, just to reach the top in this moment: 5.5.1+r484. For me this is the top I can reach because the changes Pritpal made in r485.

Wrong, no account is mandatory for the installation, just skip it (press skip on the down-right in green). I install also 5.8.0 without account. I use the installation with build mingw492.

I the previous days i tried to overcome the access violation ang got that the app not crashes if I omit the listwidget or omit the obrowse and the odlg destroy and teplace it with :=nil. In this second case the garbage objects accumulate but the apo not crash.

Best regards

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

--

You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr89gajao9O%3Dj4rgBCB5B-mBbKNyHC%2BVAiECe7e0ZvV5qQ%40mail.gmail.com.

[alex;]

Greetings to you.
Initially, the error occurred on version 5.8.3. This is what it says at the beginning of the topic.
I have confirmed that the error is happening on version 5.15. For me, the problem seems to be resolved.

WBR, alex;

пятница, 5 июня 2026 г. в 17:59:41 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Hi Alex,

there is no 5.8.3 version just 5.8.0.

The probleb is about the concurently destroy shoot between Qt and harbour.

Anyway, since there are your several posts about this error, can you summarize what, where and with what you have done to apparently solve this error.

Thank you 

Zoran

[alex;]

пятница, 29 мая 2026 г. в 18:58:33 UTC+3, alex;:

[alex;]

The solution introduces a `fPendingDelete` flag to safely defer Qt deletions via `deleteLater()`, immediately purges bind records from the global list upon explicit destruction, removes unsafe manual `disconnect()` calls that interfered with Qt's internal teardown

пятница, 5 июня 2026 г. в 21:06:06 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Thank you

I will try it and let you know

[Zoran Sibinovic]

Hi to all,

after I implemented Alex's hbqt_bind.cpp changes and several tests in the last hour and, so far, I have no apps crash anymore.

This applies on all my apps and composite.exe.

On the other hand validator.exe crashes  on the 1.,3.,4.,5. options.

For me is enough that I can now move over qt 5.5.1.

Since hbqt_bind.cpp is made by Przemyslaw and Pritpal, I will look ahead for an offical revision after their deep analysis, if they wish and have time to make it. 

Thank you Alex for the tips to solve (I hope it is) a decade problem for me.

I will continue to look for side effects, if there will be any, in the next period. 

Zoran 

[Алексей Запольский]

Zoran, why not try version 15.5.2.
validator is working on it.

WBR, alex;

сб, 6 июн. 2026 г. в 09:02, Zoran Sibinovic <zoran.s...@gmail.com>:

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/8bd0a1b0-8d6b-4f74-ad8a-b39c6deb6162n%40googlegroups.com.

[Zoran Sibinovic]

Hi Alex,

I presume 5.15.2 instead of 15.5.2 or I am wrong?

I installed 5.14.2 from qt-opensource-windows-x86-5.14.2.exe and will try it for now.

Regardinf 5.15.2, as first, I found a text that says from 5.15 Qt havo no opensource anymore and as second I cannot locate something like  qt-opensource-windows-x86-5.15.2.exe. for the installation so I sont know how handle it.

Best regards

Zoran

[Zoran Sibinovic]

Hi Alex,

I compiled harbour with Qt 5.14.2

but get a weired error in build hbqtwidgets caused in uic_scripts.prg

Have you met something similar?

Zoran

[alex;]

Yes.  5.15.2

You misunderstood the statements from Qt.

Qt 5.15.x is available to both Commercial and Open Source users.

However, after version 6 or 5.16 has been released, only Commercial users will receive further bugfixes on Qt 5.15. If you are an Open Source user and you are inconvenienced by a bug, you must upgrade to the next stable version to get a fix for the bug.

opensource.stackexchange.com

суббота, 6 июня 2026 г. в 11:49:40 UTC+3, Zoran Sibinovic:

[alex;]

Yes. https://groups.google.com/g/qtcontribs/c/WKt47Rk8rik

суббота, 6 июня 2026 г. в 13:16:47 UTC+3, Zoran Sibinovic:

[alex;]

The last time I recompiled, there were no errors. I'm going to try a clean compilation now.

суббота, 6 июня 2026 г. в 13:16:47 UTC+3, Zoran Sibinovic:

Hi Alex,

[alex;]

You need to update \hbqt\hbmk2_qt.hb
and to delete temporary files
\hbqtwidgets\.hbmk\win\msvc\hbqtwidgets\*.* 

суббота, 6 июня 2026 г. в 13:16:47 UTC+3, Zoran Sibinovic:

Hi Alex,

[Francesco Perillo]

I humbly propose to fork the project to try to commit the needed changes.

So that if someone wants to share some changes he can do in an organized way. And keep track of them.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/bd2c5bc1-9926-4dcc-8fc8-1750c90a80aen%40googlegroups.com.

[Zoran Sibinovic]

Hi Alex, I cannot at the moment to try the update, I will do it later. 

Can you tell me if exists some .exe for Qt 5.15.2? I looked in the archive but seems to me that every module is separate. Usually I used one file that installs everything. Also if there some special request for the installation and environment parameters.

Thank you

Zoran

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADPHLr9FdwS%2B%2BDMi17yp%2BF6n4uaxDNaEMwbweD6u4QDgf7sfmg%40mail.gmail.com.

[Zoran Sibinovic]

Hi Francesco,

about the required sign in an Qt account.

For newer versions If the skip or next is grayed out, exit the installation, disconnect the internet, restart the installation. In the first or second window there is a Settings option down left. In the manual - host/server get, type 0.0.0.0 and port 123 and you can proceed without the account. Later connect to the internet.

Zoran

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

[alex;]

To load and install Qt I use python-tool  aqt
  pip install aqtinstall
  aqt -c aqt.cfg list-qt windows desktop  
  

WBR, alex;

суббота, 6 июня 2026 г. в 16:16:45 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Hi Alex,

tried Qt 5.14.2 and no crashes of composite.exe  :)

Validator.exe stil crashes 

Next to download and compile 5.15.2

Thank you

Zoran

[Алексей Запольский]

Yes, validator started crashing after recompilation. I'm looking at what's going on.

сб, 6 июн. 2026 г. в 21:24, Zoran Sibinovic <zoran.s...@gmail.com>:

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/73d544a7-445f-4bae-a92d-3ed7a1216f36n%40googlegroups.com.

[Francesco Perillo]

Qt is a big beast and has a complex yet simple object lifecycle management. If we let it handle the deletion of the objects.

When we need to sync with harbour variables we have to understand object hierarchy AND ownership. We get these informations from qth files, where these were added by hand.

They may be wrong and they may *have been changed* in new Qt versions ! And the change not propagated to the qth file!

It is also necessary to start with a clean build of hbqt everytime we point to a new qt version, since the .h files may contain subtle differences.

When I spent endless and sleepless nights on hbQt I went to linux as a test bed: stack traces were more descriptive.

I think we should start from the "crash", understand where it happened, and go backward. 

Probably you already did, this thread is very long, split in several new threads, and informations are not easy to recap.

I bet 1 dollar the problem is in a object ownership...

[Zoran Sibinovic]

Hi Alex,

I downloaded Qt 5.15.2

The compile of harbour was ok but I have some errors in the qtcontribs compilation.

In the attachment is the log.

I presume that is another change that I have to make in hbqt_bind.cpp becouse of mingw 8.1.

I think, one, that have to be: instead  hbqt_bindGetData() = NULL;  must hbqt_bindSetData( NULL );

BR

Zoran

[alex;]

I found problem.
I commented out the SetParent lines in getsys. Everything is working now.

METHOD HbQtGet:destroy()
   HB_TRACE( HB_TR_DEBUG, "HbQtGet:destroy()" )

   IF ::widget() == "HbQtBrowse"
      ::data()[ 1 ]:destroy()
   ENDIF
// 20260607 alex;
//    IF HB_ISOBJECT( ::oEdit )
//       ::oEdit:setParent( QWidget() )
//    ENDIF

   ::oParent   := NIL
   ::sl_font   := NIL
   ::oEdit     := NIL
   ::oGet      := NIL
   ::oControl  := NIL
   //::oGetList  := NIL

   RETURN NIL

воскресенье, 7 июня 2026 г. в 12:19:51 UTC+3, alex;:

[alex;]

Hi, Zoran. In the case of the mingw error, it's better to ask the AI.

воскресенье, 7 июня 2026 г. в 12:45:11 UTC+3, Zoran Sibinovic:

[Francesco Perillo]

From a cursory look it seems that almost all the "errors" are actually warnings: probably the new compiler has more verbose defaults

--
You received this message because you are subscribed to the Google Groups "QtContribs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qtcontribs+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/94f407ec-80a8-466d-908b-58fbbee729fen%40googlegroups.com.

[alex;]

Francesco, you're more experienced. So now it's in QWidget.Setparent() should check if( p && hbqt_IsAlive( p ) )

воскресенье, 7 июня 2026 г. в 12:39:19 UTC+3, Francesco Perillo:

[Francesco Perillo]

Installing 5.8 with this trick.

Thank you

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/CADNRZ6kJYtTF4x%2BvYNzFBwi38b9_bT7M4yDxaVnqF1Q8qZThRw%40mail.gmail.com.

[Zoran Sibinovic]

Hi to all,

I am not sure what is happening ...

1. By compiling this saturday I forgot to change  QT_MINOR_VER   from 5 to 12 because for years I used Qt.5.5 and everything works.

Now on sunday no matter what qt upgraded version I tried to compile some my app with (12,14,15), I faced the error that is not found QApplication_translate().

When I looked in the ui*.prg there are lines that call it ... like It ignores the QT_MAJOR_VER=5 variable and build the ui*.prg as I run Qt4.

Looking here and there I found a lot of:  some If  ... QT_MINOR_VER ... from 4 to 9 but not above 9. Somewhere exsplicitly:  ...  QT_MAJOR_VER=5 .and.  QT_MINOR_VER=5.

The code above is not in reality, just to get the picture.

2. Also, during compiling qtcontribs in versions 5. ... 12,14,15:

C:/hb/addons/hbqt/qtcore/hbqt_bind.cpp:116:69: note: in definition of macro 'hbqt_bindGetData'
#define hbqt_bindGetData()       ( ( ( PHB_BIND_DATA ) &s_bindData )->s_hbqt_binds )

AI suggested to replace it with 

#define hbqt_bindGetData()       ( s_bindData->s_hbqt_binds )

and to be onest, the errors goes away but not sure if this change have other implications.

3.  Alex hbqt_bind.cpp have wrote in it

/*
 * $Id: hbmk2_qt.hb 482 2023-05-01 16:14:13Z bedipritpal $
 * $Id: hbmk2_qt.hb 485-candidate 2024-02-28 8:50:00Z+3 alex; $
 */
but the official Pritpal's r485 have no changes for this file, it still is r435. When I compared r435 with Alex r485-candidate I saw only Alex's modifications so what have changed in the period r435-r482? 

The contribs57.hbp seems want to unify all the versions above 5.5.1 but the things change by changing Qt, and mingw versions and ... I am not sure If qtcontribs in this state can hold them.

Best regards

Zoran

[alex;]

Hello, Zoran. I apologize. I dragged you into this.
Changes in hbmk2_qt.hb requires the QApplication_translate function. It is available in the qtcontribs\hbqt\qtcore\hbqt_misc.prg file. We just need to remove #ifdef. I already regret that I got involved in this too. I should have consulted with the authors.

WBR, alex;

понедельник, 8 июня 2026 г. в 14:14:04 UTC+3, Zoran Sibinovic:

[Zoran Sibinovic]

Hi Alex, 

no problem at all

our job is full of bugs to be solved and that will never ends  Just patience. 🤗

Best regards

Zoran

_________________________________

 Zoran Sibinović

dipl.menadžer i inž.informatike i statistike

graduate manager and engineer of informatics and statistics

Srbija / Serbia tel.+381 64 1876338

To view this discussion visit https://groups.google.com/d/msgid/qtcontribs/03b837dc-fce0-4a84-bac6-2748208a9a67n%40googlegroups.com.