- Simple management of threads
- WLanguage functions
- Characteristics of a thread
- Characteristics of threads
- Access to the existing elements and HFSQL context
- Recommendations for the processes performed by the thread
- Forbidden processes
- Processes of a WINDEV application
- Exception process and threads
Principle for running threads
An application is currently run. This application is run in a main thread
This application can start a secondary thread at any time: this thread is run in parallel to the application. This thread corresponds to a local or global procedure of the application.
This secondary thread is run in parallel to the main application. All the processes that can be run in background task can be performed in this thread: receiving emails, ...
Note: an efficient thread is a thread that waits for a specific event such as a user action, an incoming phone call or email, ...
Remark: From version 19, HFSQL is the new name of HyperFileSQL.
Simple management of threads
A secondary thread is automatically stopped when:
- the procedure corresponding to the thread is ended,
- the object that created the thread is closed.
To force the stop:
- of a secondary thread, use ThreadStop.
Versions 19 and later
of the current thread, use ThreadEnd
New in version 19of the current thread, use ThreadEnd.
of the current thread, use ThreadEnd
Caution: If a WLanguage function is currently run when a thread is stopped, the thread will actually stop after the execution of the function.
The following functions are used to manage the threads:
Characteristics of a thread
Characteristics of threads
In WLanguage, a secondary thread can be associated with:
- a procedure local to the current window,
- a procedure global to the project,
- a method of a class,
- a global method of a class.
Access to the existing elements and HFSQL context
When creating a thread, all the existing declarations, objects, elements are common:
- to the new secondary thread.
- to the thread in which the secondary thread was created (the main thread in most cases).
Therefore, these threads can access the variables, procedures, ... All the variables created once a thread is started are accessible in the thread where they have been created.
Similarly, when creating a thread, the HFSQL context is automatically duplicated. Each thread handles a specific HFSQL context. The number of HFSQL contexts is equal to the number of threads currently run. The entire HFSQL context is copied (filter, search condition, ...). The HFSQL context evolves independently in each thread.
This allows you to perform two different browse operations on the same file in two different threads.
: A filter is created on the Customer file. ThreadExecute
is used to create the thread named CTX2. The Customer file is filtered in each thread. The filter will still be enabled in the CTX2 thread even if the filter is disabled in the main thread.
- Assisted management of HFSQL errors: If several threads are used on the data files, we advise you to customize the management of HFSQL errors to avoid displaying the default windows. To do so, use HOnError to disable the automatic management of errors or to redirect the management of errors to a custom procedure (without displaying windows). See Assisted management of HFSQL errors for more details.
- Write operations and assignments in a thread: If write operations or assignments are performed in a thread, the other threads currently run do not share this information. Some inconsistencies may occur.
|Code of Thread 1||Code of Thread 2|
These two threads share the variables but they do not manage the access to the common resources. If the thread 1 is run before the thread 2, i will be set to 1 instead of 2.
Recommendations for the processes performed by the thread
Caution: The following processes cannot be run in the threads:
|Caution: it is not allowed to handle the interface (windows, controls, ...) in a secondary thread.|
When a secondary thread must interact with the user or update the interface, it must use a process started from the main thread. This process can correspond to:
- a global procedure of the project or a local procedure (of a window, ...) called by ExecuteMainThread,
- the event "Request for refreshing the display" of a window run by RequestRefreshUI.
Processes of a WINDEV application
By default, the WINDEV events (click code of a button for example), the procedures and the methods of classes can only be run by a single thread at a given time.
To allow several threads to run these processes at the same time, you must:
- Change the default management mode of threads (ThreadMode).
- Manage the critical sections and the semaphores in the code of the application.
In Java, the events (click code of a button for example), the procedures and the methods of classes can be run by several threads at the same time. To prevent several threads from running the same code at the same time, critical sections or semaphores must be added to the code of the application.
Exception process and threads
If a general exception process is set in the project initialization code, it will be triggered if an exception occurs:
- in the main thread,
- in a secondary thread started by ThreadExecute.
However, if the secondary thread triggers an exception, it will not be possible to find out its origin with ExceptionInfo
in the project code. To find out the origin of an exception in a secondary thread, the exception process must be included in the secondary thread.
Unit examples (WINDEV Mobile): The threads
Unit examples (WINDEV Mobile): The threads (pool)
Unit examples (WINDEV): The threads
Unit examples (WINDEV): The threads (pool)
Training (WINDEV): WD Using sockets
Complete examples (WINDEV): WD Video surveillance
This page is also available for…
Click [Add] to post a comment