window freezed

Hello,

I've programming in c++ with Qt 4.2.3. My problem is the following:

I've a window that is refreshing by another thread using signal-slot method. In a moment, without explanation, the window is freezed and never is refreshed. This window has some textfields that contains qstrings.

When the window is freezed, the rest of the application continue working properly.

¿What can i investigate to find the problem? I do not know where to start looking for the problem. Please, help me.

If you need another information to helpl me, please, ask me.

Thanks in advance.

Share some relevant code, please.

It's not easy, but I try to explain:

The window is created as a library that is used as object in the main application.

Before the arrival of a message from the main aplicacatio, updated a number of areas of the window:

Code:

---

switch (consoleId) {
        case 1:
        {
            itsRoleWindow->writeTF_roleConsole01(strdup(static_cast<char*> (roleActiveName[consoleId - 1])));
            break;
        }
        case 2:
        {
            itsRoleWindow->writeTF_roleConsole02(strdup(static_cast<char*> (roleActiveName[consoleId - 1])));
            break;
        }
       [...]

---

Let's see what happens in the window:

Code:

---

void roleWindow::writeTF_roleConsole01(char* c)
{
  GetForm()->setText(c,1); 
}

---

The class that receives it does this:

Code:

---

void impl_role::setText(char* c, int i)
{
  emit(signalSetText(c,i));
}

---

Code:

---

connect( this, SIGNAL(signalSetText(char*, int)), this, SLOT(slotSetText(char*, int)) );

---

Code:

---

void impl_role::slotSetText(char* c, int i)
{
  switch(i) {
   case 1: TF_roleConsole01->setText(c); break;
   case 2: TF_roleConsole02->setText(c); break;
   case 3: TF_roleConsole03->setText(c); break;
   case 4: TF_roleConsole04->setText(c); break;
   case 5: TF_roleConsole05->setText(c); break;
   case 6: TF_roleConsole06->setText(c); break;
   case 7: TF_roleConsole07->setText(c); break;
   default: break;
  };
  delete (c);
}

---

with each TF_roleConsole0x really is ui-> TF_roleConsole0x;

Therefore, writes directly to each window Textfield.

I hope I explained more or less.

Aside from the memory leak this looks ok, in the sense of nothing there would cause a window to "freeze".

Cheers,
_

You said something about threads, can we see their definition? Are there any direct calls to GUI objects from threads other than the main UI thread?

The textfield of the ui only is accessed by the method of the main application described on the second reply:

<code>switch (consoleId) {
case 1:
{
itsRoleWindow->writeTF_roleConsole01(strdup(static_cast<char*> (roleActiveName[consoleId - 1])));
break;
}
case 2:
{
itsRoleWindow->writeTF_roleConsole02(strdup(static_cast<char*> (roleActiveName[consoleId - 1])));
break;
}
[...]</code>

Ok but there are no threads here.

Ok,

I've read the complete project and this method is called from 2 differents callback methods from two different objects.

¿Is it possible that i need a mutex in the method shared by the 2 callbacks?

(sorry for my mistake at explain my problem)

You don't need any mutexes if your program does not have more than one thread. So far we have seen no evidence of more than one thread in your program.

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

If this two callback methods, use the method that writes in the textfields, i think i need to use a mutex to prevent...

Am i in an error?

Quote:

---

Originally Posted by jrodway

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

---

I don't know what is the origin of those callbacks but if this is purely Qt code, then there are no threads involved. If there are threads involved, then you can't call any UI-related code from within those callbacks.

Quote:

---

I'm not sure but each callback method i think, generates a thread because it's possible to receive the two different messages at the same time.

---

Signals and slots within the GUI do not use threads. I don't think you really understand what "thread" means. In the Qt GUI, everything is queued, and events (including slots) are executed in a sequence. It is impossible for two "messages" (whatever those are) to be received at the same time. One will be received and put into the event queue first, followed by the second one, and the code for them will be executed in the order they were put into the queue.

The handlers for some events (like paintEvent()) will execute the event only once and remove extra copies from the queue to avoid unnecessary processing, but in general things in the event queue are executed in first-in, first-out order.

I'm sorry, but i use only qt code with the ui. The rest of the application use Threads posix.

I've got two threads in the main application that try to modify the textfields of the ui. is it possible that i need a mutex to avoid the freeze of the window?

Thanks for your opinions.

Quote:

---

Originally Posted by jrodway

I've got two threads in the main application that try to modify the textfields of the ui. is it possible that i need a mutex to avoid the freeze of the window?

---

No, you cannot access any QObject from any thread other than the thread it belongs to (meaning the application thread in case of Qt widgets) and there is no way to work around this using mutexes. If there are threads involved, you need to change your application design so that those extra threads post messages to the UI thread and then the UI thread modifies state of the wigdets.

I think the signal/slot connection in the code above should take care of crossing the thread boundary properly, i.e. it should become a Qt::QueuedConnection.
But you can try to specify that explictly as the fifth argument to connect().

Independently I would strongly recommend to make the char* -> QString conversion somewhere before emitting the signal, so that the thread which created the array can delete it as well.

And, as mentioned earlier, it should do that using the correct delete operator.

Cheers,
_