Add possibility to hide and show again wxRibbonBar pages.

[wxWidgets.git] / interface / wx / thread.h

diff --git a/interface/wx/thread.h b/interface/wx/thread.h
index 4f6962af1ec8e3c933a5013979184244edb4c61e..56d79333ccbb9f023fe80e480f32e9dba9c4b91c 100644 (file)
--- a/interface/wx/thread.h
+++ b/interface/wx/thread.h
@@ -355,7 +355,7 @@ public:
                 download_chunk(buffer, 1024);     // this takes time...
 
                 {
                 download_chunk(buffer, 1024);     // this takes time...
 
                 {

-                    // ensure noone reads m_data while we write it
+                    // ensure no one reads m_data while we write it

                     wxCriticalSectionLocker lock(m_dataCS);
                     memcpy(m_data+offset, buffer, 1024);
                     offset += 1024;
                     wxCriticalSectionLocker lock(m_dataCS);
                     memcpy(m_data+offset, buffer, 1024);
                     offset += 1024;


@@ -544,7 +544,7 @@ enum wxCriticalSectionType
 
     Finally, you should try to use wxCriticalSectionLocker class whenever
     possible instead of directly using wxCriticalSection for the same reasons
 
     Finally, you should try to use wxCriticalSectionLocker class whenever
     possible instead of directly using wxCriticalSection for the same reasons

-    wxMutexLocker is preferrable to wxMutex - please see wxMutex for an example.
+    wxMutexLocker is preferable to wxMutex - please see wxMutex for an example.

 
     @library{wxbase}
     @category{threading}
 
     @library{wxbase}
     @category{threading}


@@ -584,6 +584,14 @@ public:
     */
     void Enter();
 
     */
     void Enter();
 

+    /**
+        Try to enter the critical section (same as trying to lock a mutex).
+        If it can't, immediately returns false.
+
+        @since 2.9.3
+    */
+    bool TryEnter();
+

     /**
         Leave the critical section allowing other threads use the global data
         protected by it. There is no error return for this function.
     /**
         Leave the critical section allowing other threads use the global data
         protected by it. There is no error return for this function.


@@ -697,10 +705,10 @@ enum
     @section thread_types Types of wxThreads
 
     There are two types of threads in wxWidgets: @e detached and @e joinable,
     @section thread_types Types of wxThreads
 
     There are two types of threads in wxWidgets: @e detached and @e joinable,

-    modeled after the the POSIX thread API. This is different from the Win32 API
+    modeled after the POSIX thread API. This is different from the Win32 API

     where all threads are joinable.
 
     where all threads are joinable.
 

-    By default wxThreads in wxWidgets use the @b detached behavior.
+    By default wxThreads in wxWidgets use the @b detached behaviour.

     Detached threads delete themselves once they have completed, either by themselves
     when they complete processing or through a call to Delete(), and thus
     @b must be created on the heap (through the new operator, for example).
     Detached threads delete themselves once they have completed, either by themselves
     when they complete processing or through a call to Delete(), and thus
     @b must be created on the heap (through the new operator, for example).


@@ -957,10 +965,10 @@ enum
     A common problem users experience with wxThread is that in their main thread
     they will check the thread every now and then to see if it has ended through
     IsRunning(), only to find that their application has run into problems
     A common problem users experience with wxThread is that in their main thread
     they will check the thread every now and then to see if it has ended through
     IsRunning(), only to find that their application has run into problems

-    because the thread is using the default behavior (i.e. it's @b detached) and
+    because the thread is using the default behaviour (i.e. it's @b detached) and

     has already deleted itself.
     Naturally, they instead attempt to use joinable threads in place of the previous
     has already deleted itself.
     Naturally, they instead attempt to use joinable threads in place of the previous

-    behavior. However, polling a wxThread for when it has ended is in general a
+    behaviour. However, polling a wxThread for when it has ended is in general a

     bad idea - in fact calling a routine on any running wxThread should be avoided
     if possible. Instead, find a way to notify yourself when the thread has ended.
 
     bad idea - in fact calling a routine on any running wxThread should be avoided
     if possible. Instead, find a way to notify yourself when the thread has ended.
 


@@ -1027,7 +1035,7 @@ public:
             performance issues on those systems with small default stack since those
             typically use fully committed memory for the stack.
             On the contrary, if you use a lot of threads (say several hundred),
             performance issues on those systems with small default stack since those
             typically use fully committed memory for the stack.
             On the contrary, if you use a lot of threads (say several hundred),

-            virtual adress space can get tight unless you explicitly specify a
+            virtual address space can get tight unless you explicitly specify a

             smaller amount of thread stack space for each thread.
 
         @return One of:
             smaller amount of thread stack space for each thread.
 
         @return One of: