summaryrefslogtreecommitdiffstats
path: root/examples/demos/hangman/doc
diff options
context:
space:
mode:
authorVenugopal Shivashankar <Venugopal.Shivashankar@qt.io>2021-11-11 21:54:56 +0100
committerVenugopal Shivashankar <Venugopal.Shivashankar@qt.io>2021-11-15 12:56:09 +0100
commit867604297dfc100d53a024bea25b185a4ea86765 (patch)
treec819d7ff6b6772ac5a83335acb4ab603cd9d8fb4 /examples/demos/hangman/doc
parent2fe326df30fcec15d059877629aa15b4ad594663 (diff)
Doc: Fix qdoc warnings
Change-Id: I10434c5231794ce91ddb170882ce8e55ca829cd0 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Topi Reiniƶ <topi.reinio@qt.io>
Diffstat (limited to 'examples/demos/hangman/doc')
-rw-r--r--examples/demos/hangman/doc/src/androidclasses.qdoc9
-rw-r--r--examples/demos/hangman/doc/src/baseclass.qdoc16
-rw-r--r--examples/demos/hangman/doc/src/gettingstarted-qml.qdoc18
3 files changed, 23 insertions, 20 deletions
diff --git a/examples/demos/hangman/doc/src/androidclasses.qdoc b/examples/demos/hangman/doc/src/androidclasses.qdoc
index 8e4224438..ab1c9ce8b 100644
--- a/examples/demos/hangman/doc/src/androidclasses.qdoc
+++ b/examples/demos/hangman/doc/src/androidclasses.qdoc
@@ -43,7 +43,7 @@
\li \l AndroidInAppPurchaseBackend
\li Comminucates with external store.
\row
- \li \l androidjni.cpp and InAppPurchase.java
+ \li \c{androidjni.cpp} and \c{InAppPurchase.java}
\li Communication between Google Play's billing system and C++.
\endtable
@@ -92,9 +92,10 @@
\section1 InAppPurchase.java and androidjni.cpp
- AndroidInAppPurchaseBackend makes calls directly to InAppPurchase.java and
+ AndroidInAppPurchaseBackend makes calls directly to \c InAppPurchase.java and
receives Java calls from androidjni. The demo application communicates
- with Java function using \l QJniObjects.
+ with Java function using \l QJniObject.
- \sa \l {https://developer.android.com/google/play/billing/integrate#java}{Integrate the Google Play Billing Library}, \l QJniObjects and \l QJniEnvironment.
+ \sa {https://developer.android.com/google/play/billing/integrate#java}{Integrate the Google Play Billing Library},
+ QJniObject, and QJniEnvironment.
*/
diff --git a/examples/demos/hangman/doc/src/baseclass.qdoc b/examples/demos/hangman/doc/src/baseclass.qdoc
index ef71f6b69..9aa9c7878 100644
--- a/examples/demos/hangman/doc/src/baseclass.qdoc
+++ b/examples/demos/hangman/doc/src/baseclass.qdoc
@@ -73,12 +73,12 @@
};
\endcode
- Check out the derived classes \l AndroidInAppProduct for Android and \l IosInAppProduct for iOS.
+ Check out the derived classes \c AndroidInAppProduct for Android and \c IosInAppProduct for iOS.
\section1 InAppStore
- The main entry point for managing in-app purchases. It is the base class for AndroidInAppProduct and
- IosInAppProduct.
+ The main entry point for managing in-app purchases. It is the base class for \c AndroidInAppProduct and
+ \c IosInAppProduct.
InAppStore is used for managing in-app purchases in the application in a cross-platform way.
Depending on the compiler, InAppStore checks what platform is available using \c Macros.
@@ -120,13 +120,13 @@
Once the items have been successfully registered in the store, The user can purchase them by
pressing on of the products on the apps store page. QML will call product.purchase()
- function in AndroidInAppProduct or IosInAppProduct which will open the external store's
+ function in AndroidInAppProduct or \c IosInAppProduct which will open the external store's
purchasing flow.
When a purchase has been completed regardless of success, the transactionRedy signal will be
sent to \c InAppProductQmlType, to notify QML to start finalize the transaction.
- section2 Restoring purchases
+ \section2 Restoring purchases
In the demo unlockable purchases will be saved on the apps storage. By clearing the storage
the user will lose the unlockable purchase and it cannot be purchased again, as according to
@@ -151,10 +151,10 @@
been performed, finalize() should be called. The finalize() function should be called regardless
of the status of the transaction.
- Check out the derived classes \l {AndroidInAppTransaction}{AndroidInAppTransaction} for android and \l {IosInAppTransaction}{IosInAppTransaction} for iOS.
+ Check out the derived classes \c{AndroidInAppTransaction} for android and \c{IosInAppTransaction} for iOS.
\section1 InAppPurchaseBackend
- InAppPurchaseBackend is used to create derived classs for
- AndroidInAppPurchaseBackend and IosInAppPurchaseBackend
+ \c InAppPurchaseBackend is used to create derived classs for
+ \c AndroidInAppPurchaseBackend and \c IosInAppPurchaseBackend.
*/
diff --git a/examples/demos/hangman/doc/src/gettingstarted-qml.qdoc b/examples/demos/hangman/doc/src/gettingstarted-qml.qdoc
index 63d6f1629..973c8f1d7 100644
--- a/examples/demos/hangman/doc/src/gettingstarted-qml.qdoc
+++ b/examples/demos/hangman/doc/src/gettingstarted-qml.qdoc
@@ -58,7 +58,7 @@
\section1 Registering products
Before you can operate on the products in your code, they must be
- registered in the QML graph. You start by making a \l{Store} item,
+ registered in the QML graph. You start by making a Store item,
and then create each product as a child of this.
\qml
@@ -86,10 +86,12 @@
\section1 The product declaration
For each product you must fill out the \c identifier, before the product can
- be queried from the external store. You should also always add a \l{QtPurchasing::Product::onPurchaseSucceeded}{onPurchaseSucceeded}
- and a \l{QtPurchasing::Product::onPurchaseFailed}{onPurchaseFailed} handler if you intend to provide the option to purchase
- the products. If you are also using the restore functionality, you should add a
- \l{QtPurchasing::Product::onPurchaseRestored}{onPurchaseRestored} handler to your unlockable products.
+ be queried from the external store. You should also always add a \c{QtPurchasing::Product::onPurchaseSucceeded}
+ and a \c{QtPurchasing::Product::onPurchaseFailed} handler if you intend to
+ provide the option to purchase the products. If you are also using the
+ restore functionality, you should add a
+ \c{QtPurchasing::Product::onPurchaseRestored} handler to your unlockable
+ products.
The signal handlers should handle the incoming transaction. Once the transaction
has been handled appropriately, it should be finalized. For instance, when a purchase
@@ -172,8 +174,8 @@
\endqml
When the button is clicked, the purchase process is started. At some point in the future, either the
- \l{QtPurchasing::Product::onPurchaseFailed}{onPurchaseFailed} handler will be called (for example if the user cancels the transaction), or the
- \l{QtPurchasing::Product::onPurchaseSucceeded}{onPurchaseSucceeded} handler will be called.
+ \c{QtPurchasing::Product::onPurchaseFailed} handler will be called (for example if the user cancels the transaction), or the
+ \c{QtPurchasing::Product::onPurchaseSucceeded} handler will be called.
\note The button is only enabled if the product's status is set to Registered. The registration process
for a product is asynchronous, so purchases attempted on a product before it has been successfully registered
@@ -186,7 +188,7 @@
in the external market place.
To start the process of restoring purchases, you should call the restorePurchases() method in the
- \l Store object. This will cause the onPurchaseRestored handler to be called in each of the application's
+ \c Store object. This will cause the onPurchaseRestored handler to be called in each of the application's
unlockable products that has previously been purchased by the current user.
Continuing on the example from before, which could be some sort of role-playing computer game, lets imagine