Application architecture

[nish]

Perhaps you could introduce some example applications organization. It would be very helpful and would look at the problem from another perspective (especially if you include a bit of pseudocode).

Thanks for all answers.

The example you provided is very good and most of apps i worked on were using the similar approach.

Coming to the QApplication issue.
Inheriting from QApp should be done when you want to extend the original class's functionality. For example QApplication extends QCoreApplication to provide GUI.
Now lets suppose you app is requried to run in console mode, then you need to use QCoreApplication, which you cant because you are inheriting from QApplication.
Similarly you cannot use other Classes like QtSignleApplication (inherites from QApplication), because now you have to change your MyApp code to inherit from QtSignleApplication.

Furthurmore, you are designing you main Security class inherited from QApplication, which makes it Qt depended. All your serial generation/comparision etc should be independent of Qt to use in in any C++ as you mentioned.

I can explain why your protection in main() is easy to defeat, but i dont think they are implemented as such in your real program.

[m15ch4]

nish:

instead of subclassing qapplication, why not have a seperate global class?

Did you mean that instead of creating objects (MainWindow, DataProcess, DataAccess, ...) in the main.cpp file (or QApp class) we should create those objects in separate class (eg. Engine) which will be instantiated in main.cpp?

[nish]

not really. I already agreed that your design is good. Its just the case of Inheriting from QApp that is think should be revisited.

[d_stranz]

Furthurmore, you are designing you main Security class inherited from QApplication, which makes it Qt depended. All your serial generation/comparision etc should be independent of Qt to use in in any C++ as you mentioned.

I should make clear that all of the security functions -are- implemented independently of my LicensedApp class; this class -is- the Qt wrapper that gives access to the non-Qt security features and exists mainly to supply an event loop. These are in fact shared with non-Qt (e.g. MFC) apps.

[m15ch4]

d_stranz:

Sixth, I use Model/View components extensively. For each collection of information stored in the Document, there is usually a Model that serves as the interface between the Document and the table, tree, or other widget that displays it. These Models are owned by the MainWindow. Typically, the Document emits a "collectionChanged( const SomeCollection & )" signal, and the Model listens for it on a matching slot. The Model stores the pointer to the collection that is passed by the Document in its signal, and serves it up via the Model's data() method.

Do you write your own Model classes or you use those from Qt (like QAbstractItemModel)? If your data is stored in custom collection, then you probably have to reimplement at least data() method to fit your data organization (in SomeCollection).

I would be very thankful if you could explain this.