Qt-interest Archive, January 2008
Little threading problem (QThread)
Pages: Prev | 1 | 2 | Next
Message 16 in thread
Thanks for the reply Etienne.
You are very right. If i inherit all the members from QObject and
QGraphicsItem in my MYGraphicsItem then it can be dangerous.
I implemented the same in this way :-
I created the same pop Up menu in the MyGraphicsView class and i made a
condition that if item is selected then execute the pop up menu.
In the MyGraphicsItem class, i made it selected whenever it receives the
right click event.
I saw that MyGraphicsItem recives the mouse click event before the
execution of the pop up. Now it is working as i want.
Can you suggest me whether it is the correct way?
And one more stupid thing, if i have to create subMenu in the main popup
menu till 4 levels. In the end of the user selection. I want all the
values selected by the user. How to get that? Is there any easy way to
create subMenu up to 4 levels? otherwise i have to create a lot of menu
and put them in the addmenu() function of the menu!!!!!
Thanks alot for your help....
> I am not sure that creating a QMenu as a member of QGraphicsItem is a good
> idea, as you will have in memory a copy of the menu for each item in your
> scene. This is totally unefficient.
> Also, moing multiple inheritance from QObject and QGraphicsItem is in your
> case useless, hard to fully understand and potentially dangerous.
>
> I am almost sure that in your case, the clean and simple approach to what
> you want to do is adding a static member function to your QGraphicItem
> derived classes, that creates a menu, popup it, destroy it, do some
> actions
> on the item depending on the user choice, and return the user choice.
> You can for instance declare it like this in your item classes:
>
> class MyGraphicItem : public QGraphicItem
> {
> static int contextMenu();
> ...
> }
>
>
>
>
>
> 2008/1/22, rohitj@xxxxxxxxxxxxxx <rohitj@xxxxxxxxxxxxxx>:
>>
>> Please any one suugest, how i can create a Pop Up Menu on a
>> MyGrpahicsItem
>> (derived from QGraphicsItem)!!!!!!
>> If i inherit publically QWidget in MyGrpahicsItem then there is
>> ambiguity
>> in the functions with the same name in QGraphicsItem and QWidget.
>>
>> help
>>
>> > dear All
>> >
>> > I need to create a pop up menu which will execute on right clicking a
>> > Graphics Item in the Graphics View. Through that pop up menu , i will
>> > change the properties of the graphics item.
>> >
>> > Now my question is
>> >
>> > 1. Is it better to create a pop up in the MyGraphicsItem class derived
>> > from QGraphicsItem or the MyScene class which is derived from
>> > QGraphicsScene.
>> >
>> > 2. If I think to create pop up menu with MyGraphicsItem class then
>> > QGraphicsItem is not derived from QObject so signal slot can not work.
>> I
>> > tried to inherit QObject for MyGraphicsItem but it was giving error
>> for
>> > "Undefined vtable refrence for MyGraphicsItem".
>> >
>> > Sorry for my stupid questions but i am confused and new to QT and c++
>> > world.
>> >
>> > thanks alot.
>> >
>> > --
>> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> > "unsubscribe" in the subject or the body.
>> > List archive and information: http://lists.trolltech.com/qt-interest/
>> >
>>
>>
>> --
>> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
>> "unsubscribe" in the subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>>
>>
>
--
[ signature omitted ]
Message 17 in thread
Andreas Pakulat wrote:
> On 22.01.08 13:05:22, Babak Sayyid Hosseini wrote:
>> thank you for your reply. I discussed the topic with a few other people
>> in this group and it seems like the whole topic can be reduced to the
>> question:
>> does any thread started from the main thread stay alive after the main
>> thread is finished. Is I already said, in java this is the case for
>> non-daemon threads which is default when you start a branch thread.
>> The VM waits until are user threads are finished and exits then.
>
> This is not possible in plain C++ (or any other language that produces
> native executables). In Java you actually start the Java VM, which runs
> in the "main thread", the VM then executes your bytecode. If your code
> spawns a new thread and then returns to the VM, the VM still knows about
> the separate thread and thus is able to wait for the finishing of that
> thread before returning control to the OS, by ending its own main
> thread.
>
> Andreas
>
Yes, just need to make sure the main thread is finished "last". Thats it.
Regards,
Babak Sayyid Hosseini
--
[ signature omitted ]
Message 18 in thread
Babak Sayyid Hosseini wrote:
> Hi,
> in the following tiny piece of code a QThread object is instantiated for
> which its start() method is called. We wonder why on my machine
> [
> Distributor ID: Ubuntu
> Description: Ubuntu 7.10
> Release: 7.10
> Codename: gutsy
> Qt Version: 4.3.2
> g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> ]
>
> the output is:
> 0
> 1
> 2
> 3
>
> wheras somewhere else (friends machine) the same code produces:
> -----------------> i 0
> -----------------> i 1
> -----------------> i 2
> -----------------> i 3
> 0
> 1
> 2
> 3
>
> as expected.
>
>
> Compilation:
> g++ -c -pipe -g -D_REENTRANT -Wall -W -DQT_SHARED -DQT_GUI_LIB
> -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I.
> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I.
> -I. -o mainprogthread.o mainprogthread.cpp
> g++ -o thready mainprogthread.o -L/usr/lib -lQtGui -lQtCore -lpthread
>
>
>
> Code:
>
> mainprogthread.cpp:
> ----------------------------
> #include "mainprogthread.h"
>
> MainProgThread::MainProgThread() {}
>
> MainProgThread::~MainProgThread() {}
>
> void MainProgThread::run() {
> for (int i=0; i < 4; i++) {
> printf("-----------------> i %d: \n", i);
> }
> }
>
> int main ( int , char** ) {
>
> MainProgThread* mainProgThread = new MainProgThread;
> mainProgThread->start();
> //guiThread->wait();
> for (int i=0; i<4; i++) {
> printf("%d \n", i);
> }
> }
>
>
> mainprogthread.h:
> --------------------------
> #ifndef MAINPROGTHREAD_H
> #define MAINPROGTHREAD_H
>
> #include <QThread>
> #include <iostream>
> /**
> @author Babak Sayyid Hosseini
> */
>
> using namespace std;
>
> class MainProgThread : public QThread {
>
> public:
> MainProgThread();
> ~MainProgThread();
> void run();
> };
>
> #endif
>
>
> After calling start() the OS thread-scheduler should register the new
> Thread and branch it away from the main thread. Calling start must end up
> in a call to run() which dumps a string on stdout. I wonder why we have 2
> different behaviors.
> Any hints are welcome.
>
> Babak Sayyid Hosseini
Georg Fritzsche to Babak Sayyid Hosseini
Reply
hi,
with thread you mostly don't know about the execution order... i've got
the same result as you.
if i change it into:
mainProgThread->start();
mainProgThread->wait();
... i get what you expected.
regards,
georg
----------------------------
Babak S. Hosseini to Georg
Reply
Hello Georg,
yes you don't have any guaranty about the execution order of the threads in
this case, but,
we MUST see both printf outputs. One from the printf inside the run() Method
and one
from the main thread. We wonder why one is "omitted".
--
[ signature omitted ]
Message 19 in thread
Babak Sayyid Hosseini wrote:
> in the following tiny piece of code a QThread object is
> instantiated for
> which its start() method is called. We wonder why on my machine
[...]
> wheras somewhere else (friends machine) the same code produces:
[...]
> as expected.
Why are you expecting that the 2 threads do their work in a certain
order? Don't expect anything here, unless you synchronize them.
You're not waiting for the 2nd thread when you exit your program, so i
guess both results can be seen as "expected".
Cheers,
Peter
--
[ signature omitted ]
Message 20 in thread
Peter Prade wrote:
> Babak Sayyid Hosseini wrote:
>> in the following tiny piece of code a QThread object is
>> instantiated for
>> which its start() method is called. We wonder why on my machine
> [...]
>> wheras somewhere else (friends machine) the same code produces:
> [...]
>> as expected.
> Why are you expecting that the 2 threads do their work in a certain
> order? Don't expect anything here, unless you synchronize them.
> You're not waiting for the 2nd thread when you exit your program, so i
> guess both results can be seen as "expected".
>
> Cheers,
> Peter
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/
Of course the execution order can not be guaranteed.
Since the branch thread in registered in the os thread scheduler,
we expected to see at least both printf dumps.
The topic is clear now, though. Please see other replies to my posting.
Regards,
Babak Sayyid Hosseini
--
[ signature omitted ]
Message 21 in thread
Babak Sayyid Hosseini wrote:
> Hi,
> in the following tiny piece of code a QThread object is instantiated for
> which its start() method is called. We wonder why on my machine
> [
> Distributor ID: Ubuntu
> Description: Ubuntu 7.10
> Release: 7.10
> Codename: gutsy
> Qt Version: 4.3.2
> g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> ]
>
> the output is:
> 0
> 1
> 2
> 3
>
> wheras somewhere else (friends machine) the same code produces:
> -----------------> i 0
> -----------------> i 1
> -----------------> i 2
> -----------------> i 3
> 0
> 1
> 2
> 3
>
> as expected.
>
>
> Compilation:
> g++ -c -pipe -g -D_REENTRANT -Wall -W -DQT_SHARED -DQT_GUI_LIB
> -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I.
> -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I.
> -I. -o mainprogthread.o mainprogthread.cpp
> g++ -o thready mainprogthread.o -L/usr/lib -lQtGui -lQtCore -lpthread
>
>
>
> Code:
>
> mainprogthread.cpp:
> ----------------------------
> #include "mainprogthread.h"
>
> MainProgThread::MainProgThread() {}
>
> MainProgThread::~MainProgThread() {}
>
> void MainProgThread::run() {
> for (int i=0; i < 4; i++) {
> printf("-----------------> i %d: \n", i);
> }
> }
>
> int main ( int , char** ) {
>
> MainProgThread* mainProgThread = new MainProgThread;
> mainProgThread->start();
> //guiThread->wait();
> for (int i=0; i<4; i++) {
> printf("%d \n", i);
> }
> }
>
>
> mainprogthread.h:
> --------------------------
> #ifndef MAINPROGTHREAD_H
> #define MAINPROGTHREAD_H
>
> #include <QThread>
> #include <iostream>
> /**
> @author Babak Sayyid Hosseini
> */
>
> using namespace std;
>
> class MainProgThread : public QThread {
>
> public:
> MainProgThread();
> ~MainProgThread();
> void run();
> };
>
> #endif
>
>
> After calling start() the OS thread-scheduler should register the new
> Thread and branch it away from the main thread. Calling start must end up
> in a call to run() which dumps a string on stdout. I wonder why we have 2
> different behaviors.
> Any hints are welcome.
>
> Babak Sayyid Hosseini
Georg Fritzsche to Babak Sayyid Hosseini
Reply
hi,
with thread you mostly don't know about the execution order... i've got
the same result as you.
if i change it into:
mainProgThread->start();
mainProgThread->wait();
... i get what you expected.
regards,
georg
----------------------------
Babak S. Hosseini to Georg
Reply
Hello Georg,
yes you don't have any guaranty about the execution order of the threads in
this case, but,
we MUST see both printf outputs. One from the printf inside the run() Method
and one
from the main thread. We wonder why one is "omitted".
-- ttyl. babak
----------------------------
Georg Fritzsche to me
Reply
because the process that started the thread in this case was already
finished before the mainProgThread was executed. the behaviour
especially varies greatly with different platforms.
and... damn - i forgot to reply to the list ^^
anyway... regards,
georg
----------------------------
Babak S. Hosseini to Georg
Reply
Hello Georg,
I already had this suspision, but this should not be the case due to the
fact that the new thread has to be independent from the main thread as soon
as the os thread scheduler has registered it for execution.
Here is a little piece of code in java that shows the "independence":
public class Test {
public Test() {
System.out.println("Output from main thread");
MyThread m = new MyThread();
m.start();
}
public static void main(String[] args) {
Test t = new Test();
System.out.println("Main thread is exiting now !");
}
class MyThread extends Thread {
public void run() {
for (int i=0; i<10; i++) {
System.out.println(" output from MyThread Thread_i : " + i);
}
}
}
}
Output (as expected):
babak@blue:~/Desktop$ java Test
Output from main thread
Main thread is exiting now !
output from MyThread Thread_i : 0
output from MyThread Thread_i : 1
output from MyThread Thread_i : 2
output from MyThread Thread_i : 3
output from MyThread Thread_i : 4
output from MyThread Thread_i : 5
output from MyThread Thread_i : 6
output from MyThread Thread_i : 7
output from MyThread Thread_i : 8
output from MyThread Thread_i : 9
-- ttyl. babak
-----------------------------
Georg Fritzsche to me
i'd call java with its vm special.
the common case is that if the app reaches the crts exit routines all
threads belonging to it also die...
and in your case thread->start() is called, but that only schedules the
thread for eventual execution - thread->run() is never called.
regards,
georg
-----------------------------
Babak S. Hosseini to Georg
In java we have to distinguish between daemon threads and user threads.
The state of a daemon thread is not considered in case a java program is
ending.
The garbage collector thread is a daemon thread for example. It is stopped
as
soon as your program finishes execution.
User thread states are considered though. When finishing a user state, the
runtime
checks, whethere there are other user threads and the program is not
finished until those user threads are finished.
So in qt case. we saw a different behavior than in java as far as threads
are considered.
The thread I start in my qt thread example has to be a kind of "daemon
thread" in java terms. I would like to know, whether one can configure that
behavior.
I would like to put our conversation back again into the qt newsgroup to be
a help for others if it is ok for you.
Babak Sayyid Hosseini
--
[ signature omitted ]
