never did someting like displaying 8 pictures parallel. Most of my work uses only a single output.
For a fast output in my ad-scanner i use SDL, its a bit tricky to use but very fast. With SDL you can also display your Images without creating QImages.
I think its worth a try.
i'm biased against forcing the end user to download and install an app dependency
Then provide them with your app.
The problems with codecs are: licenses.
That's why Linux distributions often do not provide all available codecs by default and the user of the distribution has to install them explecetly (like on Ubuntu with bad/ugly versions of GStreamer plug-ins from universe repository). Same for Qt I guess: Qt projects does not want to get in troubles because of providing codecs for not really free media formats (not free, full of patents, ...).
The idea is simple. Imagine you would like to know if something happens and based on it, you need to take an action. This scenario occurs in Qt via signal-slot approach. Knowing if something happens is usually carried out with emitting a signal. Taking an action is usually done via slot.
Now imagine you have Student Class and you need to know if the name of the student has been changed. The following simple minimal working example illustrate this scenario:
I did get a call stack on the crash that did show me that it was indeed an access violation caused by QT handling a clicked signal.
Are you allowed to post the full stack trace? Change the names of your application's functions to preserve confidentiality, but don't change the structure.
Also, compare the Release mode stack trace with the Debug mode stack trace -- do you notice anything unusual?
Am I just not seeing the full picture somehow and this access violation caused by a QT clicked event is actually caused by something else?
I'm sure that the debugger isn't lying when it says that the access violation occurs at the instant when QMetaObject::activate is called. But we don't know whether it's QMetaObject's fault or not.
Think about the button and the signal. Is it always the same button that causes the crash, or do different buttons cause it? Look at the signal parameters -- are they deletable? Are they custom types? Look at the slot(s) connected to those buttons -- does the receiver object get deleted at any point?
Also, which thread processes the file -- your GUI thread, or a secondary thread?
Does the problem still exist if you build your code against Qt 4.8.7 (the last version in the Qt 4 series)
I wouldn't be surprised but normally when I run in release with a debugger attached it shows me somewhat useful information when it crashes. I'm sure this is not as reliable for debug information but I would just like to know next time I encounter a weird crash that says it's being caused by QT.
That's the nature of bugs: We know how the system is supposed to behave, but since it is misbehaving we can't make any assumptions on what's going on. So, the most systematic way forward is to gather as much detailed evidence as feasible. It could be a bug in your code; it could be a bug in Qt's code.
You might even encounter a Heisenbug where the program's behaviour changes when you run it in Debug mode. This could either frustrate you to no end, or it could provide a different set of clues to help you track down the bug.
i'm thinking of another solution, have a method in actionHandler to take the rows to be updated. the table will set the selected rows numbers, and the tree will set *. that way processing will be done the actions handler now.
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.