KrAsyncMain: Difference between revisions
mNo edit summary |
mNo edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
==Description== | ==Description== | ||
'''#include "krasyncm.hpp"''' | '''#include "krasyncm.hpp"''' | ||
Beginners to OS/2 PM programming usually find this message processing style in which PM programs have to be written highly disturbing. The IBM open class library helps somewhat by providing ICurrentApplication::run(). However, the associated handler concept is not easy to comprehend, and the programmer is still responsible for not blocking the message queue for more than a few milliseconds. | Beginners to OS/2 PM programming usually find this message processing style in which PM programs have to be written highly disturbing. The IBM open class library helps somewhat by providing ICurrentApplication::run(). However, the associated handler concept is not easy to comprehend, and the programmer is still responsible for not blocking the message queue for more than a few milliseconds. | ||
By inheriting from KrAsyncMain, you get a new main() function with the following nice features: | By inheriting from KrAsyncMain, you get a new main() function with the following nice features: | ||
* It runs in its own thread on idle priority. This means that you can do whatever you want in this main() function, the system will still be able to multitask as if no system load existed, you'll be able to move around your app's window on the screen etc., but main() will still get as much CPU power as possible under these circumstances (usually, this will be approx. 99.9%). | * It runs in its own thread on idle priority. This means that you can do whatever you want in this main() function, the system will still be able to multitask as if no system load existed, you'll be able to move around your app's window on the screen etc., but main() will still get as much CPU power as possible under these circumstances (usually, this will be approx. 99.9%). | ||
* It will receive commands send to your window, thus benefiting from the advantages of the message system while avoiding its disadvantages (s.a). | * It will receive commands send to your window, thus benefiting from the advantages of the message system while avoiding its disadvantages (s.a). | ||
* It will receive a startup message, i.e. you can now easily write commands which are supposed to be part of the program's initialization, but which also require that the system parts of the application already are fully functional (i.e. that IApplication::current().run() | * It will receive a startup message, i.e. you can now easily write commands which are supposed to be part of the program's initialization, but which also require that the system parts of the application already are fully functional (i.e. that IApplication::current().run() is already running). | ||
==Derivation == | ==Derivation == | ||
Line 30: | Line 30: | ||
You can construct one object of a derived class and attach it to your application's main window. Though it might be possible to create more objects and destruct them, this is not recommended. | You can construct one object of a derived class and attach it to your application's main window. Though it might be possible to create more objects and destruct them, this is not recommended. | ||
The construction of this object should take place immediately before calling IApplication::current().run(). | The construction of this object should take place immediately before calling IApplication::current().run(). | ||
'''Overload 1''' | '''Overload 1''' | ||
Line 38: | Line 38: | ||
===main() function=== | ===main() function=== | ||
====main==== | ====main==== | ||
You must overwrite this pure virtual function. It is called on program startup and whenever a command is received by your application's main window. This command may come from any source, including having been issued from within this function. | You must overwrite this pure virtual function. It is called on program startup and whenever a command is received by your application's main window. This command may come from any source, including having been issued from within this function. | ||
The command is passed in the parameter event. Have a look at the enumeration commands to find out what commands are used. | The command is passed in the parameter event. Have a look at the enumeration commands to find out what commands are used. | ||
public: | public: | ||
virtual void main (IEvent & event) = 0; | virtual void main (IEvent & event) = 0; | ||
Note: This function is called once at a time only. You don't need to take care of any synchronization issues, but you must be aware that no further commands will be processed by this function while it is still running. | Note: This function is called once at a time only. You don't need to take care of any synchronization issues, but you must be aware that no further commands will be processed by this function while it is still running. | ||
Latest revision as of 21:32, 7 October 2022
Description
#include "krasyncm.hpp"
Beginners to OS/2 PM programming usually find this message processing style in which PM programs have to be written highly disturbing. The IBM open class library helps somewhat by providing ICurrentApplication::run(). However, the associated handler concept is not easy to comprehend, and the programmer is still responsible for not blocking the message queue for more than a few milliseconds.
By inheriting from KrAsyncMain, you get a new main() function with the following nice features:
- It runs in its own thread on idle priority. This means that you can do whatever you want in this main() function, the system will still be able to multitask as if no system load existed, you'll be able to move around your app's window on the screen etc., but main() will still get as much CPU power as possible under these circumstances (usually, this will be approx. 99.9%).
- It will receive commands send to your window, thus benefiting from the advantages of the message system while avoiding its disadvantages (s.a).
- It will receive a startup message, i.e. you can now easily write commands which are supposed to be part of the program's initialization, but which also require that the system parts of the application already are fully functional (i.e. that IApplication::current().run() is already running).
Derivation
KrAsyncMain inherits both from ICommandHandler and from IThreadFn.
Constructors
KrAsyncMain is a virtual class. You cannot construct objects of this class. Instead, derive a new class from KrAsyncMain which defines at least a new function main.
You can construct one object of a derived class and attach it to your application's main window. Though it might be possible to create more objects and destruct them, this is not recommended.
The construction of this object should take place immediately before calling IApplication::current().run().
Overload 1
public: KrAsyncMain (IWindow* mainWindow);
Public Functions
Constructors
KrAsyncMain
KrAsyncMain is a virtual class. You cannot construct objects of this class. Instead, derive a new class from KrAsyncMain which defines at least a new function main.
You can construct one object of a derived class and attach it to your application's main window. Though it might be possible to create more objects and destruct them, this is not recommended.
The construction of this object should take place immediately before calling IApplication::current().run().
Overload 1
public: KrAsyncMain (IWindow* mainWindow);
main() function
main
You must overwrite this pure virtual function. It is called on program startup and whenever a command is received by your application's main window. This command may come from any source, including having been issued from within this function.
The command is passed in the parameter event. Have a look at the enumeration commands to find out what commands are used.
public: virtual void main (IEvent & event) = 0;
Note: This function is called once at a time only. You don't need to take care of any synchronization issues, but you must be aware that no further commands will be processed by this function while it is still running.
However, if commands are received while the function is still running, these commands are not lost. Instead, they are stored in a FIFO (first in, first out) queue and being processed as soon as the function is left.
Enumerations
commands
public: typedef enum {cmdStartUp = 1, cmdFuncFinished, cmdUser} commands;
These command codes are being passed in IEvent::parameter1() to main. These are their meanings:
- cmdStartUp
- Used on first call after program startup
- cmdFuncFinished
- Reserved for internal use
- cmdUser
- This and all subsequent values are free for you to use for your own commands. Be aware, however, that you must avoid conflicts with other commands sent to your application's main window, e.g. IDs of menu items.