Incredibuild and “cannot create temporary il file”

This is caused by latest MS security update. After applying these two 3126587 and 3126593 previous versions of Incredibuild stopped working.

Command line error D8037 : cannot create temporary il file 

The solution is to uninstall it

On Windows 10 the responsible update is KB3135173

Next steps

Also it’s necessary to disable these updates in auto-update!


More info:–cannot-create-temporary-il-file

QML Notes


F5 for instant reload,


class UltraView : public QQuickView {
    void keyPressEvent(QKeyEvent*event) override {
             auto oldSource=source();

F10 and F11 for slowing down animations

else if(event->key()==Qt::Key_F10) { 
} else if(event->key()==Qt::Key_F11) {

QML Live editing

QML Lint

Qml & QtQuick

Qt documentation

QML Canvas

QML States

QML MouseEvents

QML c++ integration

QtQuick painted items

QML charts

QML Diagrams

QML & QtQuick blogposts

QML Selection, multiselection, rectangle-selection

QML Tools

QML Applications


Other topics

Qt 5.5.0 an Qt 5.5.1, QWebEngine, QtWebKit and ICU

Notes about compiling QtWebEngine (instead of QtWebkit) together with Qt 5.5.1

Qt 5.5.0 configure switches for ICU:

configure \
    -icu \
    -I Q:\SharedLibraries\icu4c-51_1\icu\include \
    -L Q:\SharedLibraries\icu4c-51_1\icu\lib64

Starting with 5.5.1 it shouldn’t be necessary to compile and ship ICU libraries because ICU should be included in Qt package itself.

Compile QtWebkit

It’s necessary to compile it as standalone module.

cd Qt/qtwebkit
perl Tools\Scripts\build-webkit

Simpler solution

Much easier solution seem to be to use  😉


  • When changing configure settings, it’s sometimes necessary to perform complete clean rebuild. The  best way how to do that is download completely new source package.
  • nmake clean or nmake distclean unfortunately didn’t work for 100%
  • It’s necessary to have installed Ruby, Python and Perl

Source links:

Other info:

Qt – This application failed to start because it could not find or load the Qt platform plugin “windows”

This application failed to start because it could not find or load the Qt platform plugin “windows”.

As temporary fix, set following environment variable in VS (Debugging->Environment):QT_PLUGIN_PATH=q:\SharedLibraries\Qt32\bin\plugins

Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10 part III

So, one more attempt. Previous articles (part1, part2) mentioned possible solutions to fix crash insinde the QTreeWidget and QAccessibleTableCell.

Unfortunately, deselecting current item still doesn’t fix all issues. The problem with deselection is that it’s not handled correctly via QAccessibleTableCell:

If current index isn’t valid, QAccessible doesn’t correctly update currect QAccessibleTableCell object which caused all this evil crashes.

So there are two ways how to fix it. One is to manually set QAccessibleTableCell but I didn’t find a way how to do that. The second way is to disable QAccessible for Property editor. Unfortunately it’s not an easy task. In QAccessible exists method setActive:


But this method works only with AccessibleObserver class but not with QPlatformAcessibility which handles real QAcessible::isActive result. Because of this it’s necessary to update setActive method in file qacessible.cpp inside the Qt.

Original method:

void QAccessible::setActive(bool active)
  for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)

and updated version:

void QAccessible::setActive(bool active)
    if ( QPlatformAccessibility *pfAccessibility = platformAccessibility() )

  for (int i = 0; i < qAccessibleActivationObservers()->count() ;++i)

In case you will find better way how to turn off accessibility, please let me know.

But there is still one more problem. Occasionally OS X decides to switch accessible back on:

And this is probably the reason why everything works ok on older OS X but not on 10.10. Because OS X 10.10 randomly turns accessible on which causes this crash. Accessible is usually turned on when opening some modal dialog.

This explains why opening an empty dialog increased the probability to crash the application. The only solution I have found is to disable QAccessible every time the PropertyEditor is cleared up.

Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10 part II

As mentioned in the first part of this article, the workaround with focus unfortunately didn’t work. In some cases application is still crashing. So after next hours of debugging and unsuccessful consulting the problem on stack overflow I probably found a the core reason of this bug and the solution too.



The core of this problem doesn’t lie in the QTreeModel, but in Qt implementation of Cocoa Accessible. The problem is that although the PropertyTree is correctly cleared, there is object QAccessibleTableCell which isn’t correctly updated after



This means that although the PropertyTree and TreeWidget is empty, the QAccessibleTableCell object still holds m_index variable to invalid element. And when


is executed, m_index is translated to QTreeWidget element pointer and accessed. And this means that application completely crashes.

The solution is pretty simple. Together with property editor clear set also current index and selected index to NULL.

	propertyManagers->treeWidget()->setItemSelected(NULL, false);

And that is it. Thanks for this your application will not crash any more (on this bug 😉 ).


Crash in QTreeWidget / QTreeView index mapping on Mac OSX 10.10

This crash took me about 40hr+ to replicate and find a way how to eliminate it (unfortunately not to fix it). This crash occurred only on OS X 10.10, not 10.9, not Linux, not Windows.


Bug occurred in slightly modified QtTreePropertyBrowser where we have additional buttons for each property.


When any of these buttons caused property tree refresh, application randomly crashed. But when these actions were executed by buttons outside of the property tree, everything worked fine.

Thread 0 Crashed:: Dispatch queue:
0   org.qt-project.QtWidgets      	0x0000000103f49290 QTreeModel::index(QTreeWidgetItem const*, int) const + 176
1   org.qt-project.QtWidgets      	0x0000000103f4950b QTreeModel::parent(QModelIndex const&) const + 75
2   org.qt-project.QtWidgets      	0x0000000103f23bb7 QTreeView::isIndexHidden(QModelIndex const&) const + 71
3   org.qt-project.QtWidgets      	0x0000000103f17e0d QTreeView::visualRect(QModelIndex const&) const + 93
4   org.qt-project.QtWidgets      	0x0000000103ec490d QAccessibleTableCell::rect() const + 29
5   org.qt-project.QtWidgets      	0x0000000103ec46f2 QAccessibleTableCell::state() const + 146
6   libqcocoa.dylib               	0x00000001071913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58
7   libqcocoa.dylib               	0x000000010718df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398
8              	0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115
9              	0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56
10              	0x00007fff95e2a62a CopyAttributeNames + 216
11          	0x00007fff9768cbce _AXXMIGCopyAttributeNames + 252
12          	0x00007fff976950c6 _XCopyAttributeNames + 385
13          	0x00007fff97671109 mshMIGPerform + 199
14      	0x00007fff99259c79 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
15      	0x00007fff99259beb __CFRunLoopDoSource1 + 475
16      	0x00007fff9924b767 __CFRunLoopRun + 2375
17      	0x00007fff9924abd8 CFRunLoopRunSpecific + 296
18           	0x00007fff9695d56f RunCurrentEventLoopInMode + 235
19           	0x00007fff9695d2ea ReceiveNextEventCommon + 431
20           	0x00007fff9695d12b _BlockUntilNextEventMatchingListInModeWithFilter + 71
21              	0x00007fff95a489bb _DPSNextEvent + 978
22              	0x00007fff95a47f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
23  libqcocoa.dylib               	0x000000010717b29d QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 2093
24  org.qt-project.QtCore         	0x0000000104b0337d QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 381
25  org.qt-project.QtWidgets      	0x0000000103e6c192 QDialog::exec() + 514

I updated methods from signals-slots mechanism to QEvent system. Unfortunately this didn’t help as well. Next attempt was QTimer usage instead of QEvent or signal-slot to simulate real click. But also without any success.

0   org.qt-project.QtWidgets      	0x000000011112f62e QTreeModel::data(QModelIndex const&, int) const + 46
1   org.qt-project.QtWidgets      	0x00000001110aa7bb QAccessibleTableCell::state() const + 347
2   libqcocoa.dylib               	0x00000001143913aa QCocoaAccessible::hasValueAttribute(QAccessibleInterface*) + 58
3   libqcocoa.dylib               	0x000000011438df7e -[QMacAccessibilityElement accessibilityAttributeNames] + 398
4              	0x00007fff95dea26e NSAccessibilityEntryPointAttributeNames + 115
5              	0x00007fff95e275af -[NSObject(NSAccessibilityInternal) _accessibilityAttributeNamesClientError:] + 56

With a lot of luck I finally found the reason for the crash. It’s caused by erasing a property tree (and inner QTreeWidget) together with an active focus on this widget. Unfortunately I’m not able to fix it in the QtCore because according to callstack there is only some QModelIndex manipulation without any sight of what’s going wrong.


The effective solution how to fix this wrong behaviour is to temporally set focus to another widget (or parent), clear the tree and set focus back to property tree. Unfortunately this solution doesn’t work. Check part II of this article for better solution

  QWidget* pObject = qobject_cast<QWidget*>(m_propertyBrowser->parent());
  if (pObject!=NULL);

If anyone know how to fix that, I will be glad for any info.

WordPress upgrade

Error message:

wordpress update Could not create directory
This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php


#set persmissions for writing to all
find -type d -print0 | xargs -0 chmod 777
find -type f -print0 | xargs -0 chmod 666

#revert back
find -type d -print0 | xargs -0 sudo chown deploy
find -type f -print0 | xargs -0 sudo chown deploy

find -type d -print0 | xargs -0 chmod 755
find -type f -print0 | xargs -0 chmod 664

#set permissions to correct user
sudo chown deploy ./wp-includes/js/tinymce/plugins/wpemoji/*

Additional links

OS X codesign failed: bundle format is ambiguous (could be app or framework)

This error can be caused by many things but I know about one more which I didn’t find anywhere else ;-).

In case you compile and deploy your app by using qtmacdeploy and sign your application immediately, everything will probably works fine. The problem occurs, when you need to copy your application to different location (for example during dmg building). In such cases, this error can occur:

bundle format is ambiguous (could be app or framework)

Althought codesign is executed as always, singing isn’t successful:

codesign --deep --force --verbose --sign "$SIGNNAME" ./
/path/ bundle format is ambiguous (could be app or framework)

The problem is, that during the copy it’s necessary to keep all symbolic links inside frameworks. Without this, singing will fail.

So instead of

cp -r ./Source ./Destination

it’s necessary to use

cp -R ./Source ./Destination

QDialog::reject can be invoked multiple times

When user use ESC to close the dialog and press it very quickly two or more times in a row, QDialog::reject can be invoked also multiple times.

This is very dangerous and unpredictable because in case your reject will contain some one-time-execute routine the application will start crashing.

The only solution I found is to add these routines to QDialog destructor instead of to reject/accept.