Announcement

**Bern Ertl** · 16 Jun 2001, 09:40 AM

Edwin,

I'm not sure I understood you correctly, but I've wanted to send
info to a dialog before the DIALOG SHOW statement and I used:

Code:

   DIALOG NEW hDlg&, Title$,,, 100, 80, _
              %WS_POPUPWINDOW OR %WS_CAPTION OR %WS_MINIMIZEBOX OR _
              %WS_MAXIMIZEBOX OR %WS_SIZEBOX OR %WS_MAXIMIZE TO hDlg2&

   PostMessage hDlg2&, %WM_USER+1, x&, y& 'Pass data

   ' ** Display the dialog
   DIALOG SHOW MODAL hDlg2&, CALL DlgProc TO Result&

------------------
Bernard Ertl

**Eric Pearson** · 16 Jun 2001, 11:35 AM

Edwin --

I'm not sure I understand either. WM_INITDIALOG and WM_NOTIFY are two different messages. How could WM_NOTIFY be sent while you are "in" WM_INITDIALOG? At most they would be sent sequentially, one immediately after the other.

Hmmm... unless, that is, something in your WM_INITDIALOG handler is causing WM_NOTIFY to be sent? Is that what you are saying?

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited June 16, 2001).]

**Edwin Knoppert** · 16 Jun 2001, 01:51 PM

Bernard,
I'm using a postmessage at the moment.

My question was wrong, i wanted it to be confirmed.

Eric,
I am creating a custom control during init.
The control notifies the parent of a certain state.
In this case right after creation.
This all happens while WM_INITDIALOG is still processing of course.
I can not imagne, Windows blocks these messages during this period.

This is the order:

WM_INITDIALOG
> CreateWindow
< Send Parent a notify
Return from creation
Exit WM_INITDIALOG

------------------

**Chris Boss** · 16 Jun 2001, 02:26 PM

Edwin;

The problem is PostMessage. While SendMessage sens a message
immediately, PostMessage waits until all other messages
in the que are completed first, which would include WM_INITDIALOG.

So if you create a control in WM_INITDIALOG and expect it to send
a WM_NOTIFY messages to its parent upon its creation, the message
can't get there during WM_INITDIALOG if you use PostMessage.

------------------

**Dominic Mitchell** · 16 Jun 2001, 07:04 PM

The problem is PostMessage. While SendMessage sens a message
immediately, PostMessage waits until all other messages
in the que are completed first, which would include WM_INITDIALOG.

Chris, that is incorrect. SendMessage is synchronous while PostMessage is
asynchronous. That is, PosMessage returns immediately while SendMessage
waits until the message is processed before returning. That means that the
calling thread does not know when a posted message will be processed and its
quite possible that the window specified in the message will never receive
the posted message. With SendMessage the calling thread knows that the
message has been completely processed before the next line of code executes.
That is why SendMessage can be used as a simple form of thread synchronization.

------------------
Dominic Mitchell

**Chris Boss** · 16 Jun 2001, 08:13 PM

Dominic;

While the API docs may give the impression that what I said isn't true,
my description above is quite accurate.

SendMessage sends the message directly to the Window procedure
of a window, so it must be processed before SendMessage returns.
This is why SendMessage acts synchronous as you said.

Now calling PostMessage asynchronous is not quite right, just because the
API docs say the function returns immediately. The message isn't processed
asynchronously ! The message in fact is simply posted to the message queue for
the current applications thread. You might say, the message is simply
pending and it will not be processed until GetMessage gets the message from
the queue. Now the message queue processes messages in a FIFO fashion,
which means the Posted Message is the last message to get processed.

This means the WM_INITDIALOG message will finish being processed before
the posted message ever gets pulled out of the message queue, so it doesn't get
processed during the WM_INITDIALOG message. This explains Edwins
problem.

PostMessage is easily misunderstood in its usage. To be truly asynchronous
it would have to be processed in another thread and it is not. It is
still processed in the same thread as the thread that called postmessage.

------------------

**Dominic Mitchell** · 17 Jun 2001, 12:36 PM

Chris,
Your reply is a gross simplification of what really occurs.
A thread's message queue consists of a data structure that identifies a
posted-message queue, send-message queue, reply-message queue, virtualized
input queue, wake flags etc.
SendMessage sends the message directly to the window procedure of a window
only if that window was created by the same thread. If the window
was created by a different thread the message is first appended to the message
queue of the receiving thread.
PostMessage does not have to be processed by another thread to be asynchronous.
Also, the queues are not FIFO stacks in the true sense. For example, posted
messages are always returned before keyboard and mouse messages; keyboard and
mouse messages are always returned before paint messages; paint messages are
always returned before timer messages. Also, message filtering affects the
order that messages are pulled from the queue.
This priority based on the type of message can be very useful when designing applications.

For detailed analyses of threads and message queues see the following-

"GetMessage and PeekMessage internals" by Bob Gunderson in MSDN
Advanced Windows by Jeffrey Richter, "Windows Messages and Asynchronous Input"
Multithreading Applications in Win32 by Jim Beveridge and Robert Wiener.

------------------
Dominic Mitchell

**Eric Pearson** · 17 Jun 2001, 01:38 PM

Edwin --

IMO most of those details (while genuinely interesting and worthy of discussion) are not pertinent to your question and you don't need to understand them to solve your problem.

The behavior of SendMessage and PostMessage are similar to the SHELL statement and SHELL function, respectively.

SendMessage tells a window proc "process this message and give me the result". So any code that calls SendMessage will pause until the message has been processed, i.e. until a return value has been provided. That can't happen until the message is processed.

PostMessage tells a window proc "process this message when you get a chance, and discard the result because I will have moved on by then". As soon as Windowws places the message in a message que, the PostMessage function returns and the code that called PostMessage can continue. The actual message will be processed at some point in the future. In some cases, depending on how busy the system is, it can take many seconds.

So when you use PostMessage there is no way to predict when the message will be processed. If you want your message to be processed before you finish your %WM_INITDIALOG code, you must use SendMessage, not PostMessage.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited June 17, 2001).]

**jcfuller** · 17 Jun 2001, 02:08 PM

I am not sure if this is what Edwin meant but this code I believe shows a problem with
DIALOG SEND from within the WM_INITDIALOG handler.
(tested only on Win2k)

James

Code:

'=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
'Note: Click Just Cancel and gl& = 0 showing that the DIALOG SEND in WM_INITDIALOG is
'      Failing.
'------------------------------------------------------------------------------
'Click Ok and the Msg is processed.
    

#COMPILE EXE
#DIM ALL
#REGISTER NONE
#INCLUDE "WIN32API.INC"

%DLG_100_PB_OK = 101
%DLG_100_PB_CANCEL = 102
%DLG_100_PB_OK = 101
%MY_MSG = %WM_USER + 1
GLOBAL gl&
'==============================================================================
CALLBACK FUNCTION _
  DLG_100_PB_CANCEL_CB AS LONG
  
  DIALOG END CBHNDL
END FUNCTION  
'==============================================================================
CALLBACK FUNCTION _
  DLG_100_PB_OK_CB AS LONG
    DIALOG SEND CBHNDL,%MY_MSG,0,0
    MsgBox "DIALOG SEND CBHNDL,%MY_MSG,0,0"
    DIALOG END CBHNDL
END FUNCTION  
'==============================================================================
'===========================================================================
CALLBACK FUNCTION _ 
  DLG_100_CB AS LONG

  SELECT CASE CBMSG
    CASE %WM_INITDIALOG
      DIALOG SEND CBHNDL,%WM_SETICON,1,LoadIcon(0,BYVAL %IDI_APPLICATION)
      DIALOG SEND CBHNDL,%MY_MSG,0,0
    CASE %MY_MSG  
      gl&=10
      FUNCTION = 1
  END SELECT
END FUNCTION
'===========================================================================
FUNCTION _ 
  Create_DLG_100 ( _
    BYVAL hParent		AS LONG _
  ) AS LONG

  DIM hDlg                              AS LONG
  DIM lRetVal                           AS LONG
'---------------------------------------------------------------------------
  DIALOG NEW hParent, _
            "", _
            0, _
            0, _
            240, _
            120, _
            %DS_MODALFRAME OR %DS_3DLOOK OR %WS_OVERLAPPED OR %WS_VISIBLE OR %WS_CAPTION OR %WS_SYSMENU, _
            %WS_EX_DLGMODALFRAME, TO hDlg
  
'---------------------------------------------------------------------------
  CONTROL ADD BUTTON, _
              hDlg, _ 
              %DLG_100_PB_OK, _
              "OK", _
              186, _
              6, _
              50, _
              14, _
              %BS_PUSHBUTTON OR %BS_CENTER OR %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP, _
              , CALL DLG_100_PB_OK_CB
'---------------------------------------------------------------------------
  CONTROL ADD BUTTON, _
              hDlg, _ 
              %DLG_100_PB_CANCEL, _
              "Cancel", _
              186, _
              26, _
              50, _
              14, _
              %BS_PUSHBUTTON OR %BS_CENTER OR %WS_CHILD OR %WS_VISIBLE OR %WS_TABSTOP, _
              , CALL DLG_100_PB_CANCEL_CB
  DIALOG SHOW MODAL hDlg,CALL DLG_100_CB TO lRetVal
  FUNCTION = lRetVal
END FUNCTION
'===========================================================================
FUNCTION _
  PbMain ( _
  )AS LONG
  
  Create_Dlg_100 0
  MsgBox FORMAT$(gl&)
END FUNCTION

------------------

**Semen Matusovski** · 17 Jun 2001, 02:54 PM

Guys --
don't forget that DDT is subclassed.

Code:

   #Compile Exe
   #Dim All
   #Register None
   #Include "WIN32API.INC"

   CallBack Function DlgProc As Long
      Select Case CbMsg
         Case %WM_INITDIALOG
            MsgBox Hex$(getWindowLong(CbHndl, %GWL_WNDPROC)),, Hex$(CodePtr(DlgProc))
      End Select
  End Function

  Function PbMain
     Dim hDlg As Long
     Dialog New 0,  "", , , 240, 120 To hDlg
     Dialog Show Modal hDlg Call DlgProc
  End Function

SendMessage works fine, but ... in original proc.
Executing Dialog Show, DDT imitates WM_INITDIALOG (real event already was in Dialog New) and in this moment doesn't transfer message to DlgProc).

Summary. Windows works as expected. DDT works like Bob wrote.

------------------
E-MAIL: [email protected]

**Edwin Knoppert** · 17 Jun 2001, 10:46 PM

Semen,
I think you are right and confirmes my tought.

Chris,
I use postmessgae only to SOLVE my problem
I don't wanted to use it.

As i said to semen, i think the DDT messagepump is not transferring all messages properly whil being in the WM_INIT.

I added another sendmessage IN WM_INITDIALOG to instruct my control.
This results in another problem.
These problems do not occure if i use postmessage from the WM_INIT like:

Case %WM_INITDIALOG
PostMessage 10000

Case 10000

Do all stuff here...

This is no good if you try to build a good control..

------------------

[This message has been edited by Edwin Knoppert (edited June 18, 2001).]

Announcement

WM_NOTIFY is not received in DDT during WM_INITDIALOG

WM_NOTIFY is not received in DDT during WM_INITDIALOG

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment