|
|
Randor wrote: Can you clarify what your saying here and give reference?
Common Knowledge - and CK should never require a reference...!
The difference between using WM_USER and WM_APP is that some of the Win32 common controls use messages in the WM_USER + some value range. For example, the Toolbar control uses at least WM_USER + 1 to WM_USER + 69 .
WM_USER starts at 0x0400 while WM_APP starts at 0x8000 . No standard controls use any messages in the WM_APP+ range - this is a Microsoft "standard" for lack of a better word. The range 0xC000 to 0xFFFF is used BY RegisterWindowMessage(...) so you should also avoid that range - there could be applications that look at a message's value (or what range it falls into) to determine how it should be processed (or not).
Need a custom message value, and do not want to waste a registered window message on it? Then use WM_APP as the base value for the message.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
I am not the original poster. I know the difference between the custom ranged messages, but I am asking for clarification of WM_USER being obsolete?
-David Delaune
|
|
|
|
|
Randor wrote: [...] but I am asking for clarification of WM_USER being obsolete?
Not really obsolete, but not appropriate for inter-application exchange - right from MS documentation:
0 through WM_USER – 1 Messages reserved for use by the system.
WM_USER through 0x7FFF Integer messages for use by private window classes.
WM_APP through 0xBFFF Messages available for use by applications.
0xC000 through 0xFFFF String messages for use by applications.
Greater than 0xFFFF Reserved by the system for future use. MS Sez: Message numbers in the second range (WM_USER through 0x7FFF) can be defined and used by an application to send messages within a private window class. These values cannot be used to define messages that are meaningful throughout an application, because some predefined window classes already define values in this range. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use these values. Messages in this range should not be sent to other applications unless the applications have been designed to exchange messages and to attach the same meaning to the message numbers.
Message numbers in the third range (0x8000 through 0xBFFF) are available for application to use as private messages. Message in this range do not conflict with system messages.
So! While you CAN use WM_USER as a base for custom inter-application messages, it is implied, if not recommended, that you use WM_APP .
This is from the VC++6.0 docs, BTW - 7+ years ago qualifies as common knowledge in my book.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: Not really obsolete
Thanks,
Thats all I was asking.
James R. Twine wrote: So! While you CAN use WM_USER as a base for custom inter-application messages, it is implied, if not recommended, that you use WM_APP.
This is from the VC++6.0 docs, BTW - 7+ years ago qualifies as common knowledge in my book.
Actually it recommends 0xC000 through 0xFFFF for 'string' messages which are RegisterWindowMessage unique 'named' messages. It does not recommend WM_APP for inter-process messages.
http://msdn2.microsoft.com/en-us/library/ms644947(VS.85).aspx[^]
Anyway, you continue to give answers to questions that I have never asked. All I was asking is for clarification of WM_USER being deprecated.
Lets not continue this discussion any further.
Best Wishes,
-David Delaune
|
|
|
|
|
this might help http://msdn2.microsoft.com/en-us/library/ms644931(VS.85).aspx
|
|
|
|
|
The referenced page does not say anything about WM_USER being deprecated. Communicating with some of you CP guys seems difficult at times. I thought I asked a simple question, but perhaps its my fault for not wording it more correctly.
Forget I ever posted a response to your message. Lets not continue the discussion further.
Best Wishes,
-David Delaune
|
|
|
|
|
Cool down, Dave. You're one nice guy. I think rather his statement wasn't properly worded. He's one cool guy too, but he isn't a native English speaker and probably meant to say what James said.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
sorry brother, if you find my comment disturbing.. actually MSDN itself said that obselete the WM_USER message.. programmer must use WM_App for there app. see http://www.google.co.in/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Fwww.codeproject.com%2FKB%2Fdialog%2Fmessagemgmt.aspx&ei=M23VR-LTCYqw6wOd4KjuBA&usg=AFQjCNGOy-JJOUzm0IcFD1QRhl-CIBjUgA&sig2=5dFoUmK6ihWxHsr24k9NZw
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote:
WM_USER is now obselete, application should use WM_APP or use registered window message
What gives you this idea? It's far from obsolete. It's intended for "use by private window classes" where as WM_APP is "available for use by applications".
Steve
|
|
|
|
|
Stephen Hewitt wrote: What gives you this idea? It's far from obsolete. It's intended for "use by private window classes" where as WM_APP is "available for use by applications".
right you say, but the guy who posted the original question is intended to use it for Inter process communication!
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
All this discussion on WM_USER/WM_APP is great, but what about the
reason it works in debug build but not in release build?
What's up with that?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: All this discussion on WM_USER/WM_APP is great, but what about the
reason it works in debug build but not in release build?
generally main question lost between secondary question
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hello all,
I have made a dialog based application and i want to provide its title text at runtime i.e (when i click on exe then it should read a text file and should get dialog box title value)......
Can anybody please help me in doing this....
Thanks in advance....
|
|
|
|
|
|
SetWindowText("The_Title_String"); if you are using MFC.
Maxwell Chen
|
|
|
|
|
SetWindowText() also works without MFC.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: SetWindowText() also works without MFC.
I did not write the handle argument hWnd .
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: did not write the handle argument hWnd.
might be it's CWnd::SetWindowText
"If it were machines, the pair_programming seem to work, but for humans it is pair_crackdown that seems to work! " - Nisamudheen
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
Hi,
I have an Application which supports multiple languages. I want to print the time as the footer string of a page( in AM/PM format).
On English OS(WinXP) this is printing fine but when I am using French OS, the AM/PM information is not being displayed in the footer. Please help me in this regard.
Also, I am using the GetTimeFormat() to set the time format. What should I do?
Thanks and Regards,
Purusottam Mishra
Purusottam Mishra
Software Engineer
|
|
|
|
|
Raj-Ekoham DwitiyoNasti wrote: I have an Application which supports multiple languages. I want to print the time as the footer string of a page( in AM/PM format).
Isn't that blatant ignorance of user will? A usability horror?
But OK.
Which locale and/or lpFormat are you feeding into GetTimeFormat ?
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all. Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Raj-Ekoham DwitiyoNasti wrote: Also, I am using the GetTimeFormat() to set the time format. What should I do?
You should be looking at the string that GetTimeFormat() is formatting. Forgo the printing and footer stuff until that is right.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi Exprts,
I am so curious to get the link file path but I could not. I am creating a shell context menu. As I click on link file(shortcut) Program resolve the name before the InvokeCommand() function. But in QueryContextMenu() I can detect the link file type through flag CMF_VERBSONLY but I could not get the link file path.
How can I do this?
|
|
|
|
|
hi everyone,
good afternoon to all.i am facing problem in adding the picture in the form. in my form i added one picture box i set the properties like bitmap but in image box i have to set the path.if i am giving path like E:\savitri like this it is giving error like illligal characters so please enter correct path. please tell me how can i add a picture in the form.picture means i want to browse from different dirctories and add to picture box please help me.
THANKU IN ADVANCE,
savitri
|
|
|
|
|
Are you using WinForms, then right click on the picture box and select choose Image option. And posting to WF message board will help more.
And from the Déjà vu experience, I think you are using VC++/MFC and assuming you are refering picture Box for picture control, you mentioned you set the type of picture control to bitmap and in the image field you need to set the ID of the bitmap resource. for that add the bitmap to the resource and change the ID if needed, use that ID in the Image option box. The path cannot be used directly.
|
|
|
|