Thread Question - Understanding Use of Sleep

[David Roberts]

Cracked it. :coffee2:

The 'Control Set Text' in MainThread was also causing a problem.

So, I used PostMessage there as well.

If we change 'Post' to 'Send' in MainThread then we get NewThread coming in after MainThread.

If we change 'Post' to 'Send' in NewThread then we get a pedestrian NewThread.

However, both functions now spit out iCount& so fast that I have had to restrict the reporting to iCount& increments of 50 for my machine. I'd be interested in knowing if that is OK for other machines.

So, no 'Dialog DoEvents 0' now and we are using a primary thread plus secondary thread as Gary's original post.

I've done a bit of tidying up as well and if I may coin a phrase from you know who "Look, Ma, no globals".

#Compile Exe
#Dim All
#Include "Win32API.inc"

%Start = 100
%Main = 101
%Extra = 102
%Private = %WM_USER + 501

Function PBMain() As Long
  Local hDlg As Long
  Dialog New Pixels, 0, "Test Code",300,300,200,200, %WS_OverlappedWindow To hDlg
  Control Add Button, hDlg, %Start,"Start Thread", 50,10,100,20
  Control Add Label, hDlg, %Main,"<main thread count>", 50,40,100,20
  Control Add Label, hDlg, %Extra,"<extra thread count>", 50,70,100,20
  Dialog Show Modal hDlg Call DlgProc
End Function

CallBack Function DlgProc() As Long
  Local hThread As Long
  
  Dim Text( 0 To 1 ) As String
  Text(0) = "Main"
  Text(1) = "Thread"
  
  Select Case As Long CB.Msg
  
    Case %Private
      Control Set Text CB.Hndl, %Main + CB.lParam, Text(CB.lParam) + Str$(CB.wParam)
      
    Case %WM_COMMAND
      
      Select Case As Long CB.Ctl
        
        Case %Start
          If CB.CtlMsg = %BN_CLICKED Then
            Thread Create NewThread(CB.Hndl) To hThread
            Thread Close hThread To hThread
            MainThread(CB.Hndl)
          End If
              
      End Select ' WM_COMMAND
      
  End Select ' CB.Msg  
                     
End Function

Function MainThread (ByVal hWnd As Long) As Long
  Local iCount&
  Do
    Incr iCount&
    If iCount& Mod 50 = 0 Then PostMessage hWnd, %Private, iCount&, 0
  Loop Until iCount& > 200000
End Function

Thread Function NewThread (ByVal hWnd As Long) As Long
  Local iCount&
  Do
    Incr iCount&
    If iCount& Mod 50 = 0 Then PostMessage hWnd, %Private, iCount&, 1
  Loop Until iCount& > 200000
End Function

[Chris Holbrook]

            Thread Close hThread To hThread

pardon?

[David Roberts]

Gary used it in his opening post and I left it as is. Do a POFFS 'Find exact match' search on 'hthread to hthread'. You may be surprised at who uses it. You actually participated in two threads in June 2006 which uses it and one was a Source code entry by yourself on Wednesday June 14 2006 at 19:38. You actually program when Coronation Street is on?

[Chris Holbrook]

You actually program when Coronation Street is on?

I do not use a television, although I do own a postcard signed by Julie Goodyear (Bet Lynch).

My aim is to strive to improve my Windows programming skills which were in a fairly primal state in the year in question. This is a higher goal for me than consistency! I can only apologise for past misdemeanours.

Embracing prolixity with the benefit of newcomers to programming as my guiding light, I will point out the general danger of having a function sacrifice its handle to a return value like a snake swallowing its own tail (Kekulé's inspiration?). If the function fails, then you are left with a returned value indicating failure, but no handle to the failed object, and therefore no alternative than to soldier on with a failed object lurking around using resources, or to kill the parent process. Unless you enumerate the threads and have enough evidence to pick the right one. In the specific I don't know how recoverable a failed THREAD CLOSE generally is.

Anyway as a programming technique it is best avoided. Some of us learnt our programming skills in an environment which encourages recycling of variables, but one can go too far.

Ooo, I've just had an MCM moment! Must be old age.

[David Roberts]

I wholeheartedly agree, Chris.

I prefer to keep the handle open just in case I need to use it. As I said above "I write expecting to add more" - just look at those 'Select Case' statements - I can easily add, perhaps for debugging purposes; in fact I did during testing.

I don't forget to close the handle because in my own code I use

CASE %WM_DESTROY
  IF hThread THEN THREAD CLOSE hThread TO lResult

The exercise for me here was to solve a problem before I had no hair left and not 'clean up' Gary's code. I am not suggesting Gary's code needed cleaning up although I don't like 'If CB.Msg = %WM_Command And CB.Ctl = 100 And CB.CtlMsg = %BN_Clicked' especially that '100'.

Dirty code will find itself being introduced as we strife to solve something; with most folks I reckon. However, on solving we should then clean up. When I'm 'on the attack' I don't write with newcomers in mind either. When I post in the Source Code forum I still don't write with newcomers in mind but I do strive to publish good clean code there. Having said that I would probably look at some of my early entries and say "Oh, dear" but that is probably true for anyone who contributes to the Source Code forum from time to time.

Perhaps we should have a 'sticky' for newcomers: You will find some good programming practice in all of the forums but beware that in forums other than the Source Code forum when the 'blood is up' dirty code may creep in. Regrettably we could grow potatoes on some of the code in the Source Code forum but the likelihood is less than elsewhere.