I don't have a solution for you, only a warning. If you intend to parse arbitrary C++ files from anywhere, rather than some terribly cut-down subset whose layout you know intimately, you're going to find this very hard to do. Very, very hard!
To parse C and C++, you start by using a very powerful preprocessor. These preprocessors are inevitably written by hand (they are not based on a theoretic foundation like regular expressions or context-free grammars).
As far as I am aware, there is no open source which will produce a standalone parse tree for you. The consensus (search the web) is that you really need to try to leverage an existing C++ compiler to do such a job. You could look at gcc, or perhaps more likely clang. I still don't think you'll get what you want out of them.
If all you want to do is some hacky approximation which just extracts #include statements so that you can follow them then you could do something with QRegularExpressions. Correctly locating & extracting the definition of functions in .cpp/.h files will be harder --- you'll probably end up making all sorts of assumptions as to where definitions start & end more on a line-by-line basis than via regular expressions or proper parsing. It may do you for your purposes, provided you are happy with some vague approximation which is not robust.
I don't have an answer currently because your example is clearly not minimal. I can confirm it crashes even with a more recent version of Qt. However, the code is pretty convoluted especially for doing drag and drop.
I think there's room for simplification that would likely end up in a cleaner and easier to understand code base.
It doesn't. In fact, if it worked as you expected it would break SOLID
it's definitely a serious design flaw
Sorry to be brutal: No, it's not a flaw, you just didn't understand the design of model/views.
To help you get a better idea of what is going on, try use the same model with 2 different treeviews. In only one of the view call setRootIndex, and then trigger the filtering.
Why do you want to "display it in my map using one MapQuickItem only"? You will need to create multiple MapQuickItem instances to display multiple markers on map at once. You can create them statically (if their number is known in advance) or dynamically (if not).
That's the solution I usually choose when encountering such a problem, but in my case there can be multiple views open at the same time, which do not need to be in sync.
If anyone else has a suggestion how to resolve this problem I am open to suggestions.
A colleague asked for me on the mailing list and that was the answer:
regarding the 'deprecated' state of XmlPatterns: There wont be an further development for this module, but I also doubt that it will be removed before Qt 6. So as long as you're using Qt 5 you're safe to use XmlPatterns. Qt 6 might be still 2 years away, and as you're using it professionally, I assume that you'll probably wait at least till the release of Qt 6.1 (or even longer) anyway before upgrading your project to it. Until then there might be another Qt (conforming) solution to the problem.
So in my opinion you've got 2 options (depending on the scope and lifecycle of your project):
a) use the Xml Schema related classes from the XmlPatterns module and worry about it going away (much) later, and maybe even have a Qt (conforming) solution by then, or
b) use an external library like CodeSynthesis XSD or something similar and worry about their API changes and usage and naming patterns that differ from Qt's patterns etc.
IMHO using the Qt modules while they are still available is usually the better option.
[[by Yves Maurischat]]
I hope that helps other developers with similar questions. I mark this as solved in the sense that there is some sort of answer here, although maybe it's not completely satisfying.
@Ronak5 no, I didn't. that's probably not the problem any current test is trying to share a bool with QML and the problem is the same. but I'll remember to try it when sharing a string :)
So here is a simpler project and use a Singleton. One of the problem was that I have to declare my object in the QML when using qmlRegisterType. And I don't want to. So here is the new code, the error is the same.
I followed the example of the doc here https://doc.qt.io/qt-5/qtqml-cppintegration-definetypes.html
When I remove the dataChanged(index,index) no update gets recognized.
When I manually set the role vector to dataChanged(index, index, role) it behaves the same way as without the role specification (updates the current element, not the other ones).
Which should've helped and would've made sense as it helped in the other thread, but it didn't trigger a recomputation :( I found this blogpost which discusses the problem at hand, but solves it in QML only because he would use the dataChanged signal in C++.
EDIT: Marking this question as solved as my solution with the resetModel() worked. I had to implement a similar functionality with the same model, which was also dependent on the dataChanged signal, but it worked without resetModel. The only difference was that this functionality was encapsulated in a single "Item", e.g (color choose dialog -> change multiple textfields in the same "row").
You need to sign your installer and app executable using a certificate. You can get such cert. from many companies, just Google for it. It costs between 100-400 US dollars, certificate is usually valid for a few years (1-3).
Once you have the certificate, you can sign any exe with:
@JonB Thanks! That saved me a good deal of troubleshooting. It turned out the problem was a hard path to a file inside the C program which caused it to run correctly when invoked from it's native directory, but caused a segfault when called by Qt since the paths were different. The problem is completely fixed now.
@SGaist I am not using Labview's serial port directly because of my code contain many background functionalities. It will take time to implement all in Labview. We want to just give readable data and few User interface to Labview. So user can directly use readable value and interface in Labview.
OK, I don't want to discourage you, maybe you just want to play with it, I've said I have no knowledge. But maybe if that sort of thing was freely available from 2005 there are some more recent ones which might be better?
its been used by others for years and it worked perfectly AFAIK with gcc and clang before I started using qtcreator which complained.
Here's my guess: Previously, the assert() macro was disabled. This caused the illegal code to be effectively "commented out", so the compiler didn't detect it. After the migration, the assert() macro was no longer disabled, so the compiler now sees the bad code and (correctly) complains.