General and Desktop

Ok sorry I didn't read the Qt Threading Basics documentation before looking for examples, it's done now, (really well explained), I have all the informations, QThread emiting results as signals is the best solution I guess.

Thanks everyone!

Thanks for letting us know you have solved it. Could you please edit your title in the first post and add [solved] to it. So others will know without opening the post it's already solved. Thanks.

Hi Raethus, Welcome to devnet. Have you read "this docs":https://qt-project.org/doc/qt-4.8/qtreeview.html#details Go to the section key bindings. Greets

No solution pops too my mind apart from: get newer Qt version (4.5.3 is massively old). But you probably have reasons to use 4.5.3.

Please read description of this code in Qt Documentation.

If you use a queued connection, the thread to which the "receiving" object belongs needs to be running an event loop (that's because the event loop will fetch the signal from the queue and call the slot function). Are you 100% sure this is the case in your app? Normally your "main" (GUI) thread will be running an event loop (usually via QApplication::exec() called from your "main" function). Then sending signals over a queued connection from "background" threads to the objects that live in the "main" thread should work fine... (BTW: Maybe it would be helpful if you give some implementation details about your "multimedia timer")

[quote author="1+1=2" date="1337879775"]give a try to @ mingw32-make release @[/quote] Thanks, it works!

You won't like that, but: take a look at QtCreator and Kate sources :)

Hi. you might try to replace @this->myView->setFixedSize(400, 300);@ with @this->myView->viewport()->setFixedSize(400, 300);@ The QGraphicsView is not the widget that actually contains the scene, because the QGraphicsView also manages the scrollbars. The scene is drawn in the viewport widget, which is a little smaller than the QGraphicsView. I hope this helps. Let me know if it did not.

PS: If you have questions: Feel free to stop by in IRC on #qt-creator (freenode network) for a online chat. Of course you can also use the mailing list (Subscribe here: http://lists.qt-project.org/mailman/listinfo/qt-creator ) if you prefer that.

It works for C, but not for C++. As MinGW and MSVC have different name mangling rules for C++. [quote author="soroush" date="1337929956"]You can link MSVC-compiled binaries to MinGW-compiled clients. You will need to convert binary format and re-create symbol table and .a file. (No need to re-compile) I didn't try it myself, but heard some success stories. Check "this link":http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs for more information. [/quote]

[quote author="1+1=2" date="1337893478"]From the information we can see that what you created is a normal Qt plugin(add the proper functions have been exported), but I could not understand why you want to use it as a normal shared library(though it really works if you export proper symbols).[/quote] Because I'm lazy and don't want to change structure of project ;) Seriously, I tried to separate widget library and designer plugin. The plugin successfully linked to widget library. Also client applications linked against it. but there was no success with Qt designer. Current library (widget and plugin in same binary) works in both windows and Linux. But in windows, designer plugin for Qt creator doesn't work, because of "build key mismatch.":http://doc.qt.nokia.com/qtcreator-2.4/adding-plugins.html#matching-build-keys I'm gonna correct it tonight. Thanks

Since you do not get exceptions, how do you know that you are introducing nan then?

If you set the contextMenuPolicy to ActionsMenuContext make sure you've actually set some QActions for the widget. If you set the contextMenuPolicy to CustomContextMenu make sure you've connected to the customContextMenuRequested signal. You will have to show the context menu manually there.

Thanks! I realized that the reason it didn't work with the former path was because I created an instance of the QDialog class before the app.addLibraryPath() method was called! Problem solved!

Messy? It's just a small code excerpt showing the basic idea ;) The typedef's define the required function pointer types for the functions we want to call. If you are not familiar with function pointers, please see: http://www.newty.de/fpt/fpt.html Next we will use QLibrary to load the DLL that contains the functions, "shell32.dll" in this example. Once the library is loaded, we resolve() the desired entry point (e.g. ""SHGetKnownFolderPath") and assign the result to our function pointer variable. If the result is non-NULL, i.e. the entry point was found, we call it...

tnx sierdzio