As the main form (start up form) of the program is created by the WM_CREATE function:
When does the code placed in WM_CREATE get executed?
Before ? During ? or After ?
I have code that I want to execute right AFTER the Main Form is created and displayed.
Where would be the best place to put that code?
(The code I want to run is causing problems if I have it in the WM_CREATE function so where would be that best place to put it so that it runs right after WM_CREATE function finishes?)
Back in my Visual Basic days I oftentimes used the Form_Activate() event. In Sdk terms I believe that cleanly translates to WM_ACTIVATE. The problem with that though is that it fires every time the form is activated, i.e., minimized, then brought back up.
Quote
When does the code placed in WM_CREATE get executed?
Before ? During ? or After ?
All the code in a WM_CREATE handler executes even before control is returned to the CreateWindow() function that caused the WM_CREATE message. So the window will never become visible while code in a WM_CREATE handler is running, to the best of my knowledge.
Quote
I have code that I want to execute right AFTER the Main Form is created and displayed.
Where would be the best place to put that code?
I think you'll have to ask yourself what the effects would be of having the code execute multiple times, because I'm not sure there are any messages that are only guaranteed to occur one time after the WM_CREATE. As I just mentioned, WM_ACTIVATE will occur after WM_CREATE, but it will also occur every time the form is shown again from a minimized state. Paint handlers (WM_PAINT) also share this attribute. I know this can become tricky. I used to wrestle a lot with this issue back in my VB days. Not so much anymore. Don't know why. I don't know if this is a good idea (actually, I don't think it is), but to solve it I used to create lots of booleans to manage the problem. It tended to get buggy.
I usually handle this with a splash screen.
The splash screen has a timer (something like 3 sec). When the timer fires the code gets executed and the splash screen gets closed.
Rolf, Fred, those are some good ideas. I will test them.
Fred,
With FF3 we have WM_NCACTIVATE is that the function you are talking about?
If so, I think I can create a "run once" routine by using/setting a global.
No, just tried WM_NCACTIVATE and it does not fire after the WM_CREATE finishes.
Rolf, the timer idea may be workable for me. I will give that a try.
I am still interested in knowing when and under what conditions, these functions fire?
WM_COMMAND
FORM_CUSTOM
WM_NCACTIVATE
Quote from: Rolf Brandt on January 05, 2010, 03:59:33 AM
The splash screen has a timer (something like 3 sec). When the timer fires the code gets executed and the splash screen gets closed.
Rolf, I was thinking of putting the Timer on the main Form and have it run once and then turn off the timer. Turn off a Timer by setting the interval to zero, correct?
I tried looking up the correct syntax for the TIMER control. The information about the TIMER control seems to be missing fron the "Functions Library" I did a search on "Timer" and got no listing at all.
What is the correct syntax for setting the Timer Interval?
You could use KillTimer. Check in the SQLiteningMan project for the correct syntax. (I am right now working from a Pocket PC, so I do not have it at hand.)
Quote from: Marty Francom on January 05, 2010, 01:46:27 AM
As the main form (start up form) of the program is created by the WM_CREATE function:
When does the code placed in WM_CREATE get executed?
From my understanding WM_CREATE is executing after all the controls (child windows) on the form have been created and are ready.
You can use POST_MESSAGE API call and a CUSTOM message.
This attached sample guarantees that the code will run after WM_CREATE has complete. If there are other messages in the event queue, it may not process as the first item when WM_CREATE finishes. I've never had a problem though.
Hi Marty,
I would use Brian's approach to execute code immediately after WM_CREATE. In FF, all of the controls are created (but not shown) by the time you get the WM_CREATE message handler.
By the way, did you get my email from yesterday regarding your project that you sent me and the problem with the FORM1_UPDOWN1_CUSTOM code always causing your EN_CHANGE problem?
The code I'm using for your application is working perfectly on Win7 and WinXP. The RecSearch code is still in the WM_CREATE.
Later tonight I will email you a copy of the project that I have and also the latest FF3 so that you can test it all on your computers.
Brian, Thank you for taking the time to provide an example. Sounds like your solution may be the best approach.
Paul, Yes I got your email. And, thank you for all your help. Yes, please do email the modified project and the beta 3.06.
I am still interested in knowing when and under what conditions, these functions fire and when they should be used? And how these functions differ from each other.
WM_COMMAND
WM_NCACTIVATE
Brian, Your suggestion should work.
Questions:
Can a Form have more than one FORM_CUSTOM ?
ie: FORM_CUSTOM1
FORM_CUSTOM2
FORM_CUSTOM3
If yes, then how do you PostMessage to the correct function.
PostMessage hWndForm, %WM_FORM_CREATE_COMPLETE, 0, 0
This statement doesn't appear to me to direct the message to Form_Custom by name
so I guess it defaults to FORM1_CUSTOM function. Do I understand correctly?
In the PostMessage call what are the last two parameters (,0,0) used for?
Can PostMessage be used to post a message to any function? Can you explane how?
Only the main form custom will be called, but you can call the others within it. WM_NCACTIVATE is the activation of the Non-Client Area (Titlebar/borders). Usually before the regular activate. I usually use it to watch when windows change to block activation, etc. PostMessage is the same as SendMessage (Messages go to Windows/Controls not functions), but puts it in the queue to be processed. This is usually helpful for exiting during WM_CREATE since that is a no-no. Post a WM_CLOSE then once WM_CREATE is finished the queue will process and the WM_CLOSE will run. Returning -1 to WM_CREATE should also close the window. It causes CreateWindow to return null...not sure how FF handles that though, so would need to test (I seem to remember this coming up in beta testing and thought Paul got it to work). Winspector Spy will be a good tool for you to have to see messages. I didn't have luck finding it last google, but still have a copy if needed (Softpedia or something may have it too, make sure you get the U/Unicode edition for WinXP+).
Quote from: Marty Francom on January 05, 2010, 03:00:35 PM
Questions:
Can a Form have more than one FORM_CUSTOM ?
ie: FORM_CUSTOM1
FORM_CUSTOM2
FORM_CUSTOM3
Nope. The Form has one CUSTOM handler. That is all that is ever needed.
All Messages (except for WM_CREATE) flow through the CUSTOM handler. If you wanted to, you could handle all of your message processing there rather than use the separate message handlers (like WM_COMMAND, WM_CLOSE, WM_DESTROY, etc...). This is explained in the Help file under the "Code Editor" section. Here is how you handle the different incoming messages in the CUSTOM handler:
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 %WM_COMMAND
Case %WM_NOTIFY
Case %WM_SIZE
Case %WM_DESTROY
End Select
End Function
Quote
In the PostMessage call what are the last two parameters (,0,0) used for?
They can mean whatever you want them to mean. They are two, 32-bit values that you can pass along with your user defined message. You could even use one of those values to pass a pointer to a string, a UDT, or a manually declared block of memory. The choise is yours.
Quote
Can PostMessage be used to post a message to any function? Can you explane how?
No, you can't PostMessage to one of your user functions. The message gets posted to the applications message queue so you would have to process it from there. For example, you can not do this: PostMessage MyFunction, 0, 0
Quote from: Marty Francom on January 05, 2010, 05:24:01 AM
I am still interested in knowing when and under what conditions, these functions fire?
WM_COMMAND
FORM_CUSTOM
WM_NCACTIVATE
You should read up on the various windows messages. It would be way too hard and time consuming to explain every windows message in these forums. A good start would be to check out the WinAPI help file (it is a bit dated nowadays): http://www.powerbasic.com/support/downloads/files/Win32.zip
I usually end up reading the documentation directly from Microsoft: http://msdn.microsoft.com/en-us/library/ee663300(VS.85).aspx
For offline viewing I use a more updated set of help files available from http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm Once installed, to view those files I use the H2Viewer http://helpware.net/mshelp2/h2viewer.htm
Attached is a sample. I added a few more messages that should answer most of your questions.
I wouldn't do things in the order I did in the order in a real project if I could avoid it. This is just an example to show what occurs. In Windows programming with windows messages (event driven programming), the events may not happen in the order you expect.
When you use Sendmessage or postmessage the first parameter is the hwnd of the window to receive that message. All controls are a window (forms, textboxes, buttons, etc...). The second parameter is the message being sent. The next two are lParam and wParam are different and depend on the message. In the example I created a new message where I pass the hWnd of a textbox and a pointer to a string. The function uses these parameters to do something.
Every Window only requires one custom function. The one function can respond to as many custom events that you want to create.
Ahhhh. I think I am begining to understand PostMessage and SendMessage calls much better.