How to use separate threads for pushbuttons in QT (like SwingWorker in Java)

[artt]

Really after putting the modified walk() without args-

QObject::connect(indexate, SIGNAL(clicked()),&f,SLOT (walk()));

QObject::connect(indexate, SIGNAL(clicked()),&f,SLOT (walk()));

To copy to clipboard, switch view to plain text mode 

the indexate button do not works with big folders as C:\ , C:\Windows, just with small ones (in this instance it seems some infinite loops hapened and my PC switched off-- even so happened --despite before it I cannot copy and past in my whole windows XP along several last hours -- such situation also occures sometimes).
So thread is realized correctly.
So what code be the reason of walk() in connect().
That is probably visible in Debug Mode that shows some missing libraries. It was happened before I configured walk() method simply to console and when list of qfileinfos was at stack.
Anyway connect stament works correctly with small memory consuming examples as readxmlfromfile() [as files is just with several xml entities, written once].
So maybe I need call not Lister f (borrowed in some way from java2s), but Lister* f=new Lister()??

[anda_skoa]

Really after putting the modified walk() without args-

QObject::connect(indexate, SIGNAL(clicked()),&f,SLOT (walk()));

QObject::connect(indexate, SIGNAL(clicked()),&f,SLOT (walk()));

To copy to clipboard, switch view to plain text mode 

Yes, that looks ok.

the indexate button do not works with big folders as C:\ , C:\Windows, just with small ones (in this instance it seems some infinite loops hapened and my PC switched off-- even so happened --despite before it I cannot copy and past in my whole windows XP along several last hours -- such situation also occures sometimes).

Whatever that means, it is a clear indicator that you are not yet at the stage where you can consider using a thread.
First you need to get the code working.

So maybe I need call not Lister f (borrowed in some way from java2s), but Lister* f=new Lister()??

That depends on the life time requirements of f.
If it needs to live longer than the scope of where it is created, then it needs to be allocated on the heap or at a higher scope.

Cheers,
_

[artt]

Here I should tell you that you are wrong.
I compiled as well as with Lister* f=new Lister();
But the result is the same as in case of previous example:
The big folders contents do not render anyway,
but small folder contents render f.e. with QObject::connect(indexate, SIGNAL(clicked()),&f,SLOT (walk()));
File:13 .htaccess C:/includes 4
File:13 .htaccess C:/includes 4
File:13 .htaccess C:/includes 4
...
The big column of such lines and the message in the end of console:
The program finished unexpectedly.
The ... Filewalker.exe crashed.
So the conclusion about thread is incorrect -- exactly in thread the small folder content renders correctly.
So I have any suggestion ...
about infinitive rendering and why big folders do not render.
//But now changing
...SLOT (walkwiththread())) ...
I got
File:13 .htaccess C:/includes 4
File:13 .htaccess C:/includes 4...So the reason of infinitive loop is in
that I should use walk(path0) with arguments -- so it should resolved the issue of signals without args and slot with args -- that is not issue for thread, as it worked 2 days ago.
Anyway the issue of non-rendering of big folders remains.

[anda_skoa]

Anyway the issue of non-rendering of big folders remains.

Then this needs to be fixed before you can consider parallelizing work with threads.

Obviously the easiest solution would be to use QDirIterator, but for some reason you don't like easy solutions.

Cheers,
_

[artt]

As the post do not allow atatchmen, here I provided the link for my whole project: http://s000.tinyupload.com/?file_id=...99628647444433.
If can to see, I would be thankful.
Despite I do not think QIterator would help, despite I would try it, but not today. But when I simply displayed in console not in connect() it worked fine, after I put everything for heap. Regards, artt

[yeye_olive]

A quick look at your code convinced me that you aimed far too high for a first C++ project. You have already spent days hacking around and drawing this forum's resources, when you could have made a much more productive use of this time by:

1. learning C++;
2. learning Qt, especially by reading the documentation and starting playing with the examples;
3. building a prototype that does what you want without concurrency;
4. learning about Qt's concurrency features and the related strengths/pitfalls;
5. modifying your prototype so that long computations are offloaded to another thread.

I found this gem in your code:

int s=sizeof(Lister::listed);

int s=sizeof(Lister::listed);

To copy to clipboard, switch view to plain text mode 

If you can't see how terrible that is, then you'd better start learning C++.

Please stop allocating everything on the heap. This is C++, not Java.

Oh, and Lister::walk() does not terminate if path0 contains a subdirectory, because it makes a recursive call which traverses path0 again instead of the subdirectory. No wonder it takes too long. Nothing to do with threads, by the way.

[anda_skoa]

As the post do not allow atatchmen, here I provided the link for my whole project: http://s000.tinyupload.com/?file_id=...99628647444433.

The forum does support attachments.

Anyway, yeye_olive already took care of the answer.

Despite I do not think QIterator would help

Well, QDirIterator would help if you want to actually traverse the directory tree.
If you want to be stuck in an endless recursion, then it will not help.

So it really depends on what you want to do.

- If you want to traverse a tree of directories and store information about certain files, then use QDirIterator.

- If you want to send a thread into an endless recursion that will at some point cause the program to crash, then use your code.

Cheers,
_

[artt]

What about C++ you want I should learn? I learned about C++ a lot, but without practical application, it is nothing, especially in C++.
You are not correct in some way. Endless recursion happened when I pass walk() as slot in connect(), but when simply call walk() in main() of Lister.cpp it works well. And when I put simply walk() in single thread() in walkwiththread() it doesnt induce infinite loop. But with big folders it really could not stand, but when simply walk() put in Lister::main() it could -- you can even check, and I have write about it 1 or 2 weeks ago.
int s=sizeof(Lister::listed) - maybe it is excess here - but I simply wanted to know the size of listed Qlist, despite it really
return the sizeof Qlist type, despite I hardly conceive about size of Qlist type (what is it? it return always 4), and I need the size of listed as object. There is also such line, seems to be borrowed from my java code where it was used for testing.
Maybe, Qdiriterator should works - as whatsoever purpose did it craeted but here it is said it is slow - http://www.qtcentre.org/threads/5790...es-recursively.
But how should it works here?
Example from QtAssistant -

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     qDebug() << it.next();
 
     // /etc/.
     // /etc/..
     // /etc/X11
     // /etc/X11/fs
     // ...
 }

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     qDebug() << it.next();

     // /etc/.
     // /etc/..
     // /etc/X11
     // /etc/X11/fs
     // ...
 }

To copy to clipboard, switch view to plain text mode 

Should I remake for such kind:

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     if(it.next().fileInfo().isDir())...I need here again the QDirIteratot -- so recursion???
     else {
    couе<<it.next().fileInfo().fileName ()<<it.next().fileInfo().size ()<<it.next().fileInfo().absolutePath();
    }
 }

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     if(it.next().fileInfo().isDir())...I need here again the QDirIteratot -- so recursion???
     else {
    couе<<it.next().fileInfo().fileName ()<<it.next().fileInfo().size ()<<it.next().fileInfo().absolutePath();
    }
 }

To copy to clipboard, switch view to plain text mode 

Or maybe I misunderstand how this iterator works? Should it walk every folder recursively by itself - or how absolve the recursion here?
Or I should create whole list of folders?? Then process just files there?

[anda_skoa]

Endless recursion happened when I pass walk() as slot in connect(), but when simply call walk() in main() of Lister.cpp it works well.

This is highly unlikely since path0 never changes on recursion, so each recursion processes the same directory over and over again.
So this will always lead to an endless recursion, no matter how you involke the first iteration.

int s=sizeof(Lister::listed) - maybe it is excess here - but I simply wanted to know the size of listed Qlist

QList::size() or QList::count().

return the sizeof Qlist type, despite I hardly conceive about size of Qlist type (what is it? it return always 4)

You are likely on a 32bit machine, where a pointer is 4 bytes (32bits) long.

and I need the size of listed as object

That's the (memory) size of the list object, see above if you want to size as in "number of entries".

Maybe, Qdiriterator should works - as whatsoever purpose did it craeted but here it is said it is slow - http://www.qtcentre.org/threads/5790...es-recursively.

I think the priority should be to make it work and care about fast/slow later.
Do you prefer fast but not working?

Should I remake for such kind:

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     if(it.next().fileInfo().isDir())...I need here again the QDirIteratot -- so recursion???
     else {
    couе<<it.next().fileInfo().fileName ()<<it.next().fileInfo().size ()<<it.next().fileInfo().absolutePath();
    }
 }

QDirIterator it("/etc", QDirIterator::Subdirectories);
 while (it.hasNext()) {
     if(it.next().fileInfo().isDir())...I need here again the QDirIteratot -- so recursion???
     else {
    couе<<it.next().fileInfo().fileName ()<<it.next().fileInfo().size ()<<it.next().fileInfo().absolutePath();
    }
 }

To copy to clipboard, switch view to plain text mode 

Or maybe I misunderstand how this iterator works?

An iterator, a concept also well established in Java, provides a uniform way to linearily traverse a data structure.
The data structure might have tree form, e.g. a map, but the iterator will take care of going up and down the tree.

QDirIterator even follows the Java style iterator pattern that uses "hasNext" and "next" to drive it.
So calling next() multiple times like in your code snippet, will advance the iterator multiple times.

Maybe you want to output the file name, the size and the absolute path from tree different files into one line, maybe not.

Then process just files there?

Well, your code seems to store information about files it finds, so you can just do the same whenever the iterator points to a file.

Cheers,
_

[artt]

Sorry - the initial version of walk() was walk(path0), so it was the reason that when I put walk() in connect statement it rendered the same folder as initial path0 was written outside of walk() method, so during the recursion it referred the same folder. So when I simply put walk(path0) to walkwiththread with run() amd start() of Qthread it did not provided the issue.
So even in recursive version of walk(path0) -- the issue is how link correctly SIGNAL(clicked()) and SLOT(walk(path0)) as this pair is with arguments in last case?? Is it possible in theory? despite I could simply put walk(path0) in another void walkwrapper() method -- so it should work in connect, but should recursion be correct -- and I should underline --there were no reference from my part about endless recusrion--despite infinite list of the same folder fileinfos...
And I do not understand if Lister::walk("C:\Windows") [about 25% of C:\ drive] works when called in Lister::main() it renders all infos in console in a several minutes, even faster as it was in Java,
why it could not work in connect(..SLOT(walkwiththread())), as thread is organized correctly by me, and works with small folders -- even with that ones with several thousands of files -- but C:\Windows should have 20-30 thousands ones.

[anda_skoa]

the issue is how link correctly SIGNAL(clicked()) and SLOT(walk(path0)) as this pair is with arguments in last case??

SLOT can't reference variable names, as pointed out multiple times in this thread.

Is it possible in theory?

No, as answered multiple times already.

despite I could simply put walk(path0) in another void walkwrapper() method

Yes, as .....

and I should underline --there were no reference from my part about endless recusrion

The endless recursion was evident from the code.

why it could not work in connect(..SLOT(walkwiththread()))

There is no difference from a method's point of view whether it is called in code or via signal/slot.

as thread is organized correctly by me

Well, if you want to make your life complicated and debug a multithreading application instead, go ahead.

Cheers,
_

[artt]

You told me eventually that I cannot put SLOT(walk(path0)) even theoretically - but it is easy to solve.
I just put

Lister::walk() {
QString path0="C:\\..."
Lister::walk(path0)
}

Lister::walk() {
QString path0="C:\\..."
Lister::walk(path0)
}

To copy to clipboard, switch view to plain text mode 

But why I get
Could not load shared library symbols for 22 libraries, e.g. C:\WINDOWS\system32\ntdll.dll.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?Could not load shared library symbols for C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll.
Do you need "set solib-search-path" or "set sysroot"?Could not load shared library symbols for C:\WINDOWS\system32\uxtheme.dll.
Do you need "set solib-search-path" or "set sysroot"?Could not load shared library symbols for C:\WINDOWS\system32\MSCTF.dll.
Do you need "set solib-search-path" or "set sysroot"?
What the reason of it.
I will sure use QDirIterator, but why this recursion cannot hadle big folders.
Now it againt do not work directly for Lister::main()
but once it worked (when I put everything on heap ( in other case just 15 results appeared )- now the code is the same ).
And this message should mean some issue that could be solvable???
And then to be worked

[artt]

"Could not load shared library symbols for 22 libraries, e.g. C:\WINDOWS\system32\ntdll.dll" -- could it be the reason of this semi-workedness of walk() or it just influences
the debugging process, but no compiling and runnibg of application?

[anda_skoa]

The debugger just complains about not finding the debugging symbols for certain libraries.
That does not impact the application at all.

Cheers,
_

[artt]

Your answer about debugger is expected

---

Added after 14 minutes:

So what about idling the walk() method on big folders? It worked fine with processing at least 60000 files, then complaing about heap memory.
Why C++ cannot overcame the barrier about 20 or something less files, but it could process untill now the folders with several thousands files.
What could be the issue. I think that the experienced programmers should make some suggestion or how to debug it, how find this reason, so when I launching the debugger I get (exceot the message of missing folders) the line, that Filwalker.exe application started....So what happenning at that moments that no message no results I could not got?
So some faillure is at the very beginning of processing, as with some enough big "processable" folders the list of results appearing sequencially.
An If use QDirIterator -- it should probably use the recursion when transforming Qt code to standart C++ during run-time (or linking) stage? Should it be simpler then my option?
Anyway the resolution what barrier stop walk() for very big folders should be task for real programmers.
And maybe I need create recursion-free walk() method for the first or then second level of big-folder hierarghy, but the use current walk() method?

[anda_skoa]

I am afraid I can't make heads from what you've written.

For debugging I would make sure that there is no threading involved.
I would personally debug using logging, but setting break points in important locations and checking values should work as well.

Obviously that becomes unnecessary when using QDirIterator, since then the whole algorithm is simple linear iteration.

Cheers,
_

[artt]

I mean that Qt also has its own algorithms that translate Qt code to native C++, so its function, as well QDirIterator could be based on recursion or even more complex function?? Anyway I will use Qt iterator but the main point is if it would help, if not?
I did not found any logging infos relating to Qtcreator, and it would difficult to do as debugger do not provide any information in this case.
In general, I want to realize this application just to provide as a reference that I have real(gui) c++ app to my resume.
And except semi-workable walk() method - other issues are that ones I need to write all this info to xml file, then render to QTextEdit (I think there could be problem in assigning Qtextstream from xml file to Qt textarea with the button, as in Java, exactly that function was limited by heap memory, but the indexation vector of object was created plainly), so it could be additional point. Then I also need to add Qlabels for the displaying of search file results and other controlling information (As well as QLineEdit for entering the name of file and then passing to searchfilename() method).
Could any difficulties appear when launching app.exe directly without QtCreator?

[anda_skoa]

I mean that Qt also has its own algorithms that translate Qt code to native C++

Qt is a set of C++ libraries, its code is native C++, Qt code is compiled by the same C++ compiler as any other C++ code, there is no "translation" necessary.

so its function, as well QDirIterator could be based on recursion or even more complex function??

Yes, it could be based on explicit recursion or using a stack, etc.
The code is available so no need for speculation if this is important.

Anyway I will use Qt iterator but the main point is if it would help, if not?

Well, it is a well tested class, it is known to work, it is known to be able to traverse large directory structures.
If I had a non working code and a known to work solution, I would consider that helpful.

I did not found any logging infos relating to Qtcreator, and it would difficult to do as debugger do not provide any information in this case.

Simple logging can always be done with qDebug() or C++ output streams.

In general, I want to realize this application just to provide as a reference that I have real(gui) c++ app to my resume.

In that case you might want it to not only work but also be well written.

Cheers,
_

[artt]

Really, since the last twenty-hours I returned to the project, and almost done it, except 2 things (Some things are even simplier then in Java, despite other - not).
Qdiriterator at least work with the smallest my disk C: - but in connect() statement it freeze gui() extremely.
So I need put in thread where it works plainly, but when I put the options of Qfiledialog to basic walk() method and launched in walkwiththread() I got the run-time error where I am informed that I need probably put Qdialog to GUI thread (not separate one) - so the way out probably is the additional button for choosing file for walk() -- except it also need yet 2 file choosing for other Lister::methods so its functions could not appear the composite, just forked in some way as Qfiledialog could not implemented in separate thread.
The same situation with some kind of fatal error when I put non-static method in wrapperthread() method I also can not realize it, as this method is related in (..Lister f. wrapperthread()), when in non-static method I need to create additional object of Lister class in thread run() method. The only wayout could be making the relating button also static, as I transferred all of "Qwidgets" (buttons,labels,textedit) to Lister.h, defining it in Constructor in Lister.cpp, so all of them are non-static.

[anda_skoa]

Indeed, having methods static is really weird, very uncommon even in Java.

Glad to hear that you got it working now!

Cheers,
_