Proper place to put code

[Gary Stout]

I have a routine that alerts the user with a message box if there are pending transactions that have not been added to a deposit yet when the program first starts. I am trying to figure out where to locate the code that pops up the message box so that it appears AFTER the form is created. I have tried putting it in the WM_CREATE area and what happens is the message box appears before any other forms appear. I tried to put the code in the first control tabstop on the form, but there are issues related to that, if that control gets clicked on and has focus a second time.
When the program starts, there is a tab control on the main form and tab#2 is set to be the startup tab. I also tried to use TabCtrl_GetCurSel to detect tab#2 and that would only work if another tab was selected and then come back to tab#2.

So I guess to simplify my question, where is the best place to put code to execute after the form has been created?

Paul, I hope I didn't ask this 4yrs ago 

Thanks,
Gary

[David Kenny]

About the easiest way I know is to put a timer on the form and set the interval to 1.  Then double-click on the timer to create and open the WM_TIMER function.
Insert the following code:

Code Select Expand

   KillTimer hWndForm,wTimerID
   MsgBox "Timer fired"

David

PS,

I tried to put the code in the first control tabstop on the form, but there are issues related to that, if that control gets clicked on and has focus a second time.

You could have done it that way also with a bit more code. Try this at the top of the appropriate EN_SETFOCUS routine:

Code Select Expand

Static OneTime As Integer
If OneTime Then                  'I use this method often when I want to do something once in a sub or function.
      Exit Function
   Else
      OneTime=1
      MsgBox "Test"
End If


[Gary Stout]

Thanks David for the reply,

I tried both suggestions and for some reason, I am still getting the MSGBOX before the form appears. As soon as I click the OK button in the message box, then the form appears. Any thoughts on that?

Gary

UPDATE...seems to be working now. I am using the timer method. I tried adding a FF_DoEvent at first and that didn't change anything but increased the timer interval and I think that may have solved it. I am going to put it back to 1 and see it the message box re appears before the form.

UPDATE...setting the timer interval to 500 seems to work fine. Anything less and I am getting the MSGBOX before the form appears.

Thanks again, David

[David Kenny]

UPDATE...setting the timer interval to 500 seems to work fine. Anything less and I am getting the MSGBOX before the form appears.

Strange, I tested it on my machine.  A couple reasons for the difference come to mind. 

1) Machine speed:  Intel Core2 Quad  CPU   Q8200  @ 2.33GHz (3 years old) 

2) Initialization time:  I used a demo  with just a couple controls.  After the form creation, it wouldn't take long to add the two controls and show the window.


The second way wont work.  I just tested it and found that a EN_SETFOCUS is sent before the form is shown and not again after (unless the control looses focus and regains it).

[Paul Squires]

Hi Gary, if I understand your scenario correctly then maybe using the PostMessage approach would be a good choice:

Code Select Expand



%MSG_USER_SHOWPENDINGMESSAGE = %WM_USER + 1000


'------------------------------------------------------------------------------------------------------------------------
Function FORM1_WM_CREATE ( _
                         hWndForm As Dword, _  ' handle of Form
                         ByVal UserData As Long _  'optional user defined Long value
                         ) As Long


    PostMessage hWndForm, %MSG_USER_SHOWLOGON, 0, 0
   
End Function



'------------------------------------------------------------------------------------------------------------------------
Function FORM1_CUSTOM ( _
                      hWndForm      As Dword, _  ' handle of Form
                      wMsg          As Long,  _  ' type of message
                      wParam        As Dword, _  ' first message parameter
                      lParam        As Long   _  ' second message parameter
                      ) As Long

    Select Case wMsg
      Case %MSG_USER_SHOWPENDINGMESSAGE
           ' MsgBox " You have pending transactions...."
    End Select
   
       
End Function


[David Kenny]

Paul,

That works, but how?  I'm guessing it works along the same line as the Timer method.  The timer is waiting a specific time to pop the message up, but the message posted by PostMessage has to wait it's turn behind the other messages posted before it.  IOW, a somewhat random (but sufficiently long enough) time for the Window to finish being drawn.

BTW, I had to change the name of the equate in the PostMessage call of FORM1_WM_CREATE to match the constant declaration in your example.

[Nathan Durland]

The way I understand it, FORM1 will not display until FORM1_WM_CREATE runs to completion.  PostMessage puts the message in the queue to be handled by the FORM_CUSTOM handler, then moves on.  If you do a call or invoke a function in WM_CREATE to say, display a message box, it "pauses" the FORM1_WM_CREATE function, and therefore the display of FORM1.

[David Kenny]

Hello Nathan,

Your explanation correlates well with what we have experienced.  Both posting a custom message and using a timer allow the completion of the window creation.  The timer method is one way I came up with some time ago, but I think I will switch to the method Paul introduced to me because of the situation that Gary found. If I was going need something timed to the display of a form in a program that I write for non-personal use, I would have to spend time testing both methods to find if either method is reliable on multiple environments. 

[Gary Stout]

David,

The machine I am using is an older Dell P4 3.2ghz, 2gig ram running Mint Linux 17 as the host and Virtual Box with XP. Virtual Box slows things down slightly but not much, but that may make enough difference to require the interval setting to be longer. I am away from my developement machine until Sunday, so it will be a little while before I can try the other suggestions.

Thanks again,
Gary