|
In a single threaded app, the only difference it makes is in the order that the code is executed.
somecode
SendMessage(somewhere...
Somemore code
Some more code, as you know, does not execute until the message has been processed.
somecode
PostMessage(somewhere...
Somemore code
In this case Somemore code will execute immediately, while the message sits in a queue.
If your main program doesn't run out of things to do (e.g. go to an idle state), the message handlers will never execute.
e.g.
void doit(
{
while (true)
{
somecode
PostMessage(somewhere...
Somemore code
}
}
in this case the message will never be handled.
versus something like
void doit()
{
somecode
PostMessage(somewhere...
Somemore code
}
in this case the message may be handled (depending on what other messages are already in the queue) immeidately after the doit procedure ends.
Therefore, SendMessage lets the sender control WHEN the message is processed, while PostMessage leaves it up to the vagueries of your message handler.
Hope this helps,
Bill
Thanks for the help,
Bill
|
|
|
|
|
I'm not quite sure I fully understand your program design. What are you Send/PostMessaging to? Windows in your app, other apps on the same PC, other apps on different PCs? If the targets of the message is in another process I'd go for your current design, using PostMessage. However, if the targets are in-process I'd let each target be represented by class. On creation each of these classes registeres itself to your OnTimer-handling class (you could keep an array of CTargetClass pointers). On each WM_TIMER I would simply call a method on each class. A simple example could look like this:
class CTargetClass : public CObject_derivative
{
public:
CTargetClass (CHandlingClass* pHandler)
....
public:
void ReturnInfo (CInfo* pInfo);
}
CTargetClass::CTargetClass (CHandlingClass* pHandler)
{
pHandler->RegisterTarget(this);
}
class CHandlingClass : public CSomeBaseClass
{
....
public:
void RegisterTarget (CTargetClass* pTarget);
afx_msg void OnTimer(UINT nIDEvent);
protected:
int m_iMaxTargets;
CTargetClass* m_pTargets;
}
void CHandlingClass::CRegisterTarget (CTargerClass* pTarget)
{
m_pTargets[m_iMaxTargets] = pTarget;
m_iMaxTargets++;
}
void CHandlingClass::OnTimer (UINT nIDEvent)
{
if (nIDEvent == ID_OF_YOUR_TIMER) {
int i;
CInfo info;
for (i=0; i<m_iMaxTargets; i++) {
m_pTargets[i].ReturnInfo(&info);
DoWhateverYouNeedWithTheInfo(info);
}
}
}
Lots of stuff omitted, but I hope you get the idea.
Cheers
Steen.
"To claim that computer games influence children is ridiculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Hi,
How to access network shared resource(with UNC name) from a service
program?
for example: A service program MyService will try to open a file
MyFile.dat which resides at shared folder SharedFolder on another
machine named AnotherMachine.
\\AnotherMachine\SharedFolder\MyFile.dat
If the service MyService is configured as LocalSystem, error message
"Access to \\AnotherMachine\SharedFolder\MyFile.dat was denied."
If MyService is as valid NT account, error message
"An unknown error occurred while accessing \\AnotherMachine\SharedFolder\MyFile.dat"
Thanks for your help!
Chris Wang
|
|
|
|
|
Your second case sounds very suspicious. Have you tried stepping through the code in your service to see what happens to the file open?
What file access methods do you use? Please post the code that opens the file along with the code that produces these messages.
My guess is that the first case can be taken at face value, when the service runs as the local system account, it may not have permissions on the network resource. (One solution is to just give it permission).
The second case does not look like a permissions problem at all, but rather some other bug in the code.
HOpe this helps,
Bill
|
|
|
|
|
Hi all,
With VC7(.NET), following code give me a surprise!!!
-------snippet-------
int main(void) {
char x = 0xf0;
return 0;
}
with VC7, x = 0, with VC6 sp5, x = -15(0xf0).
when i change assignment to followings:
1) char x = static_cast<char>(0xf0);
2) char x = (char)0xf0;
3) memcpy(&x, "\xf0", 1);
4) unsigned char x = (unsigned char)0xf0;
nothing changed, x = 0.
what's the problem? me, ANSI/ISO standard, or VC7?
|
|
|
|
|
(First of all, I guess there's a typo in your post and you meant -16 instead of -15.)
This is most surprising! According to the standard, the behavior you're describing is compliant: you're trying to convert a value outside (signed) char range (namely 0xf0=240), and the standard marks this as undefined behavior. 1) 2) are equivalent, about 3) I'm not sure what's the expected behavior, and as for 4) the expected value of x is 240, not 0 (Could you check 4) again?)
What strikes me is that, despite the undefined behavior, the simplest solution, in terms of resulting code, would be that x was set to -16 (no overflow checking, direct bit pattern reinterpretation). Moreover, it is highly unlikely that MS decides to change the way its compiler behaves in such a delicate subject, thus breaking backward compatibility to gain esentially nothing. Could it be that this is a debug mode feature, and in release mode x is -16 like in the old days? Could you check that?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I think 3 would set x to the value of 'x'. You will copy one character from the string "\xf0" to the variable x. I don't think x is a standard escape character, so the \ will produce a warning and disappear at compile time leaving "xf0". The code copies 1 character so that would be the 'x'.
Thanks for the help,
Bill
|
|
|
|
|
Something else is going on. It works as expected (-16) on my VC7.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
My main program dialog is supposed to be non-maximizable,
it has a border style of thin and no maximize button.
The problem is if I run the program using a shortcut and set the
window style to maximize, it runs it maximized and it
looks like cr^P.
I've tried to then send messages to the dialog to
simulate the user clicking the restore menu item, but
this just maximizes it again.
Is there any way to intercept this maximize command and/or
dynamically resize the form back 2 its normal size?
|
|
|
|
|
Handle the WM_WINDOWPOSCHANGING message. Windows sends this message when it is about to resize a window, you can override the proposed settings to the size of your dialog.
|
|
|
|
|
If you handle the WM_GETMINMAXINFO message you can specify the allowable dimensions of your window.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
How in MFC would I intercept messages prior to them being sent or mapped/directed to the message handlers...?
I need to perform special operations on WM_PAINT, WM_LBUTTONUP etc before they're mapped to OnPaint() OnLButtonDown(nFlags, CPoint) etc...?
Can this be accomplished using OnCmdMsg()...?
Anyone know any good explanations of OnCmdMsg..?
How would I use hooks in MFC, this would allow me to hijack a message and perform some calculations, change some WPARAM's before letting it continue. Basically I want the ability to do what was possible with plain jane SDK C code.
OnCommand() WndProc() don't lend themselves nicely to what i'm trying to get done.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
HockeyDude wrote:
I need to perform special operations on WM_PAINT, WM_LBUTTONUP etc before they're mapped to OnPaint()
WM_ERASEBKGND 
HockeyDude wrote:
How would I use hooks in MFC
I don't know if it helps you but there is a article about
keyboards hook.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
|
Of course....Nish...your a genius...man if that'll let me do what I need done...wow...what a relief...only...will give me the handle to window the control is for, like SDK?
This is where one of the problems comes in..?
I wonder if theres a function for getting the MSG structure of the current message...i'm pretty sure that has the HWND...
in anycase...PreTranslateMessage sounds like a solid plan.
Cheers and thanx u kindly!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
|
Thanx Mike, but what I really need is the message AND the window handle that sent the message...so if the MSG structure's hwnd field is not NULL then i'm in business.
Thanx!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
And of course, the window handle that sent the message isn't included..it's the handle that the message is for...oh well...I think i figured it out.
Thanx again!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
|
One of books says this field is usually NULL...which would totally suck...
I would ideally like to get the hwnd from the control that "sent" the message, but it appears this is not possible with the incoming MSG, it (if anything) gives me the hwnd to the window(control) whose WndProc should handle the message. I'm really only interested in intercepting messages from two windows. The parent and child...with the parent processing all the messages. So long as I know the parent's window hwnd i could do something like this:
CParentWnd::PreTransLateMessage(MSG)
{
if(this->m_hWnd == MSG.hwnd)
AfxMessageBox("Message from parent");
else
AfxMessageBox("Message from child");
}
If this doesn't work I have more trick up my sleeve which hopefully does.
What do you think Nish...does the above sound solid for acheiving the task at hand..? Is there a better way of doing it...???
Thanx man!
Cheers
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Hello Hockey
If you actually want to figure out which control the message came from,the MSG structure has a pt member. This might be useful if you want to try and locate the exact control that send the message.
But seriously if you want to catch messages before they are handled, at the control level, you must actually start thinking of sub-classing the controls.
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
As Nish have answered the message-interception thing (I guess he literally sits at his PC every waking hour (and most hours when he should be sleeping  ) I thought I'd give it a go at the "what's OnCmdMsg all about".
OnCmdMsg gets called through two different paths: either from OnCommand or from MFC in response to a UI update. OnCommand handles only WM_COMMAND messages (not WM_PAINT or WM_LBUTTONDOWN - I'm a little unsure about WM_NOTIFY messages as they used to be WM_COMMAND messages in win16). OnCommand will quite early on call OnCmdMsg in order to do the message map lookup and dispatching.
But OnCmdMsg is also called when MFC needs info in order to update the UI. When you select a menu from the menu bar MFC will call OnCmdMsg in order to get this info. OnCmdMsg will look for an ON_COMMAND_UPDATE_UI entry in the message map and call it if present. In the ON_COMMAND_UPDATE_UI handler you can enable or disable the menu item. If no ON_COMMAND_UPDATE_UI handler is present OnCmdMsg will look for a ON_COMMAND handler for the command and if present it will enable the menu item.
Anyway, WM_COMMAND (and WM_NOTIFY?) is the only message that non-UI-window classes can handle (i.e. classes derived from CCmdTarget such as CWinApp and CDocument). But of course, UI-window classes (CView, CMainFrame etc) can handle both "ordinary" WM_xxx messages and WM_COMMAND messages.
Hope this clarifies the purpose of OnCmdMsg.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
|
Andy Metcalfe wrote:
The best explanation I've seen of what OnCmdMsg() actually does was in Paul DiLascia's article "Meandering Through the Maze of MFC Message and Command Routing" in the July 1995 edition of MSJ
Thanks for the Link Andy. But on that page I found a slight typo :-
BOOL CMyView::OnCmdMsg(...)
{
if (CMyView::OnCmdMsg(...))
return TRUE;
return m_wndGizmo.OnCmdMsg(...);
}
This must be a typo, right?
Else it will endlessly call itself!
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
Nish [BusterBoy] wrote:
This must be a typo, right?
Else it will endlessly call itself!
Well spotted Nish - you're dead right.
Presumably the call would be to CView::OnCmdMsg(), which would route the message through CMyView's message map, and - if it wasn't handled there - on to the corresponding document.
Andy Metcalfe - Sonardyne International Ltd
Trouble with resource IDs? Try the Resource ID Organiser Add-In for Visual C++
"I would be careful in separating your wierdness, a good quirky weirdness, from the disturbed wierdness of people who take pleasure from PVC sheep with fruit repositories."
- Paul Watson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
