How to test the result of QTreeWidget:itemAt(QPoint) is a QTreeWidgetItem or nil-Pointer?

[yasrick]

Hi,

answer is in subject :)

type(result) = "userdata" -> access on class properties of an nil-Pointer ends with (silent) error

I have access to the host application, so a C++ code is possible but the ugly way. :)

//yasrick

[Michal Kottman]

This should have been fixed, so right now if a pointer returned is
NULL, then 'nil' is returned in Lua. Therefore you can check it simply
like this:

local item = treeWidget:itemAt(point)
if item then
-- do processing
end

[yasrick]

Ah my mistake, I should write my lib-version. I use 4.7.2 precompiled for Windows. So I've to compile 4.8 first. That's not funny, I'll have my fun now. :)

[Michal Kottman]

On 5 March 2012 10:57, yasrick <doorsi...@googlemail.com> wrote:
> Ah my mistake, I should write my lib-version. I use 4.7.2 precompiled for
> Windows. So I've to compile 4.8 first. That's not funny, I'll have my fun
> now. :)

Do not do that (yet) - some things may break. If you use QtWebkit
module, then you will get various errors coming out of nowhere - it
seems that the QtWebkit module uses signals/slots from multiple
threads, which break Lqt. However, QtCore and QtGui seem to work fine.

If you want precompiled binaries, try the 4.7.4 version, which is the
latest working -
https://github.com/downloads/mkottman/lqt/lqt_0.9_win_qt4.7.4.zip

When you are adventurous enough, compiling Lqt isn't a big deal. You
need a working installation of Qt, CMake, and then do the following in
command line:

> git://github.com/mkottman/lqt.git or download the ZIP - https://github.com/mkottman/lqt/zipball/master
> cd lqt
> mkdir build
> cd build
> cmake ..
> mingw32-make

If you use Visual Studio, instead of the last line, open the generated
Lqt solution and build it.

[yasrick]

CMake works with Visual Studio 2008 but not with MinGW (Windows-Setup). The build part of cpptoxml works nice, but nothing else:

Fehler 1 error PRJ0019: Ein Tool hat einen Fehlercode aus folgender Quelle zurückgegeben: "Generating XML: running cpptoxml on qtcore " generate_qtcore_xml generate_qtcore_xml

at Log:

...

d:\Lua\5.1\lua.exe D:/Lua/lqt/generator/generator.lua D:/Lua/lqt/build/qtcore_src/qtcore.xml -i QtCore -i lqt_qt.hpp -n qtcore -t D:/Lua/lqt/generator/qtypes.lua -f D:/Lua/lqt/generator/qt_internal.lua

...

    Generating binding code with Lua

d:\Lua\5.1\lua.exe: D:/Lua/lqt/generator/generator.lua:89: D:/Lua/lqt/build/qtcore_src/qtcore.xml: No such file or directory

stack traceback:

 [C]: in function 'assert'

 D:/Lua/lqt/generator/generator.lua:89: in function 'readfile'

 D:/Lua/lqt/generator/generator.lua:116: in main chunk

 [C]: ?

Project : error PRJ0019: Ein Tool hat einen Fehlercode aus folgender Quelle zurückgegeben: "Generating binding code with Lua"

 ...

I'm right, if I say that cpptoxml hasn't create a xml file? CMake found the right Qt4.8 path. Is there a manual path configuration?

[Michal Kottman]

On 6 March 2012 09:37, yasrick <doorsi...@googlemail.com> wrote:
>     Generating binding code with Lua
> d:\Lua\5.1\lua.exe: D:/Lua/lqt/generator/generator.lua:89:
> D:/Lua/lqt/build/qtcore_src/qtcore.xml: No such file or directory

That is strange, could you check to see if the file exists? Also,
could you try running:

> make VERBOSE=1 qtcore

and send me a log of the process...

> I'm right, if I say that cpptoxml hasn't create a xml file? CMake found the
> right Qt4.8 path. Is there a manual path configuration?

There should be no other configuration necessary. Let me fire up a
virtual machine and see what is going wrong...

[yasrick]

Problem solved!

The cpptoxml.exe need the qtcore4.dll for executing, cmake found the path, but the exe doesn't use it. So I copied all Qt dlls to the lqt\build\bin\<Debug|Release|....>\.

After killing the WebKit parts and new cmake, the sln runs without errors.

But the QUiLoader doesn't work now:

require 'qtcore' 

require 'qtgui' 

require 'qtuitools' 

module('uiLoader', package.seeall) 

local mLoader = QUiLoader.new_local()   ---> Lua: uiloader.lua:5: attempt to call field 'new_local' (a nil value)   :(

...

So I can't test the thread topic.

[Michal Kottman]

On Mar 6, 2012 12:46 PM, "yasrick" <doorsi...@googlemail.com> wrote:
>
> Problem solved!
> The cpptoxml.exe need the qtcore4.dll for executing, cmake found the path, but the exe doesn't use it. So I copied all Qt dlls to the lqt\build\bin\<Debug|Release|....>\.
> After killing the WebKit parts and new cmake, the sln runs without errors.
>
> But the QUiLoader doesn't work now:
> require 'qtcore' 
> require 'qtgui' 
> require 'qtuitools' 
> module('uiLoader', package.seeall) 
> local mLoader = QUiLoader.new_local()   ---> Lua: uiloader.lua:5: attempt to call field 'new_local' (a nil value)   :(
> ...
>
> So I can't test the thread topic.

The memory management has changed a bit. Now you can call the class directly to get 'local' behaviour. So just call QUiLoader(), no need for new_local().

[yasrick]

Don't kill me for my stupid problems, but if I use QUiLoader():load(file) in the main script, all fine, but the pain with the methods :(. So the uiloader script is so nice, BUT if I use QUiLoader() in the uiloader.lua (means in a require file) the app crashes hard, saying "Data Driver Error   Error: 3200  Invalide work area" (twice). Is it a core problem in my code?

main.lua:

package.path = package.path .. ";./HapakELOInt/?.lua" 
package.cpath = package.cpath .. ";./HapakELOInt/?.dll" 
package.cpath = package.cpath .. ";./HapakELOInt/?"
package.cpath = package.cpath .. ";./HapakELOInt/qt/?.dll" 
package.cpath = package.cpath .. ";./HapakELOInt/qt/?" 
require 'qtcore'
require 'qtgui'
require 'uiloader'
...

uiloader.lua:

require 'qtcore' 
require 'qtgui' 
require 'qtuitools' 
module('uiLoader', package.seeall) 

local mLoader = QUiLoader()   -- CRASH 
local mObjectsByName = {} 
...

[yasrick]

QUILoader bug or not?!

To solve the problem with the external uiLoader script, move the require line after the creation of the QApplication object. 4.7.4 works w/o this requirement, but with 4.8 the new memory managment seems to need this.

But now the thread/first problem is another, the event for the context menu doesn't work anymore. The binding has no error, but the function is never called? In 4.7.4 the event was fired. Is there a new requirement to the ui, I left the context menu parts on default?

package.path = package.path .. ";./HapakELOInt/?.lua" 
package.cpath = package.cpath .. ";./HapakELOInt/?.dll" 
package.cpath = package.cpath .. ";./HapakELOInt/?"
package.cpath = package.cpath .. ";./HapakELOInt/qt/?.dll" 
package.cpath = package.cpath .. ";./HapakELOInt/qt/?" 

function SLOT(s) return '1'..s end
function SIGNAL(s) return '2'..s end
function MSG(s) haelo.ShowMessage(s) end
require 'qtcore'
require 'qtgui'
local new_MyWidget = function(...)
local this = uiLoader.load("D:\\Programme\\HapakPro\\HapakELOInt\\tree.ui")
local tree = uiLoader.findObjectByName("projecttree")
tree:connect(SIGNAL('itemSelectionChanged()'), function(self)
MSG("TEST")
end)
tree:connect(SIGNAL('customContextMenuRequested(QPoint)'), function(self, point)
MSG("FOO")
--local citem = self:itemAt(point)
--if (citem) then
-- MSG("yes")
--else
-- haelo.ShowMessage("no")
--end
end)
return this 
end

qapp = QApplication(1 + select('#', ...), {...})
qapp.setAttribute(Qt.ApplicationAttribute.AA_NativeWindows, true)  -- da das Fenster sonst in Hapak keine Events empfängt
qapp.__gc = qapp.delete -- take ownership of object
require 'uiloader'
widget = new_MyWidget()
widget:showFullScreen()
--widget:show()

[yasrick]

*Facepalm* After a crash of the developer machine, the backup destroied all changes. But after change my code again, all works fine. The nil vars works. So the topic problem is solved! :)

[Michal Kottman]

Computers sometimes (fail to) work in mysterious ways. Did you have to
change anything in Lqt to make it work, or did it work fine straight
out of the repo?

[yasrick]

The repo works fine without the webkit part. Webkit gives linker errors in VS2008. A problem was the part with the missing libraries for the compile process. I think it's a little bug in the cmake process, but not a real problem.