C / C++ / MFC

lucy13-Mar-07 5:42

lucy

13-Mar-07 5:42

I would assume you handle the menu by your main dialog, and pass the message down to your embedded dialog for further process. say,
CMyMainDialog::OnMenuCelsius ()
{
SendMessage (pEmbedDialog->m_hwnd, WUM_MENU_CELCIUS);
}

CMyEmbedDialog::WindowProc (UINT message, WPARAM wParam, LPARAM lParam )
{
if (message == WUM_MENU_CELCIUS)
{
/* display raw units to celcius values */
}
}

Trevy14-Mar-07 5:56

Trevy

14-Mar-07 5:56

Thanks Lucy for your help.
I am a beginner using MFC and I am still having problems with the concept of using messages. Can you tell me what I am doing wrong. I am getting the error C3861: 'WM_MENU_CELSIUS' identifier not found, even with argument-dependent lookup

In my header file:
// Create and assign pointers to each embedded window
_3DSEmbeddedDialog *m_dPointer[2];

In my .cpp file for main dialog:

BEGIN_MESSAGE_MAP(CMotionAnalyzerDlg, CDialog)
......
ON_COMMAND(ID_TEMPERATURE_CELSIUS, OnTemperatureCelsius)
WM_MENU_CELSIUS()
END_MESSAGE_MAP()

//2 embedded dialogs. Celsius temperature should display in the
//moteDataDlg dialog box
m_dPointer[0] = &moteDataDlg;
m_dPointer[1] = &databaseDlg;

void CMotionAnalyzerDlg::OnTemperatureCelsius()
{
SendMessage(m_dPointer[0], WM_MENU_CELSIUS);
}

In my .cpp file for embedded dialog moteDataDlg:

void MoteDataDlg::WindowProc(UINT message, WPARAM wParam,
LPARAM lParam)
{
if (message==WM_MENU_CELSIUS)
{
celsiusFlag = !celsiusFlag;
AfxBeginThread(MyThreadProc, this);
}
}

Thanks for taking the time to help me.

Trevy

lucy14-Mar-07 7:32

lucy

14-Mar-07 7:32

WM_MENU_CELSIUS is not a standard message. It's a user message. You have to define it.

For example, in your header file moteDataDlg.h, add the following:
#define WM_MENU_CELSIUS (WM_USER + 100)

for more information on WM_USER, check its entry in MSDN.

All the best!

JudyL_MD14-Mar-07 9:33

JudyL_MD

14-Mar-07 9:33

That really should be WM_APP not WM_USER. I've had instances where WM_USER has been used by some of the newer MFC classes. I don't remember off-hand which one it was but I had a problem in one of my apps that was do to something else also using WM_USER. When I changed my define to WM_APP the problem went away.

Judy

lucy14-Mar-07 9:39

lucy

14-Mar-07 9:39

thank you. that's good to know. I read wm_app again, and noticed it's said as follows:

"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.
"

Trevy15-Mar-07 5:29

Trevy

15-Mar-07 5:29

Still having problems. I know this should be simple, however, this is the second day I have been working on this problem and I still cannot seem to solve the problem.
Thank you for your help or I would not have gotten this far.
Thanks to Judy also.

void CMotionAnalyzerDlg::OnTemperatureCelsius()
{
//m_dPointer[0]->SendMessage(WM_MENU_CELSIUS,0,0);
SendMessage(m_dPointer[0]->m_hWnd, WM_MENU_CELSIUS);
}

In the function OnTemperatureCelsius() of the main dialog, if I use the statement SendMessage(m_dPointer[0]->m_hWnd, WM_MENU_CELSIUS);

I get error C2664: CWnd::SendMessageA: cannot convert parameter 1 from HWND to UINT. m_dPointer[0] refers to the embedded dialog (moteDataDlg).

I tried an alternate statement that I saw when searching for an answer. If I use the statement m_dPointer[0]->SendMessage(WM_MENU_CELSIUS,0,0), my application compiles but do not run.

Also, I am using the WindowProc correctly in my embedded dialog (moteDataDlg), I use LRESULT for the return value, initially, I used void. In the header file I declared:
protected: LRESULT WindowProc(UINT message, WPARAM wParam, LPARAM lParam);

LRESULT MoteDataDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if (message==WM_MENU_CELSIUS)
{
celsiusFlag = !celsiusFlag;
AfxBeginThread(MyThreadProc, this);
}
return 0;
}

Trevy

JudyL_MD15-Mar-07 6:21

JudyL_MD

15-Mar-07 6:21

It looks ok to me. Time to break out the debugger. Put a breakpoint on your SendMessage and follow the execution to see where it doesn't work.

Judy

Set Password to .Msg File which is backup of Outlook mail [modified]

JudyL_MD14-Mar-07 7:39

JudyL_MD

14-Mar-07 7:39

Trevy wrote:
BEGIN_MESSAGE_MAP(CMotionAnalyzerDlg, CDialog)
......
ON_COMMAND(ID_TEMPERATURE_CELSIUS, OnTemperatureCelsius)
WM_MENU_CELSIUS()
END_MESSAGE_MAP()

First, remove WM_MENU_CELSIUS from the MessageMap - you're handling it yourself from the WindowProc.

Next, WM_MENU_CELSIUS a user-defined windows message. You need to define it.

#define WM_MENU_CELSIUS WM_APP

Lastly, I would change your SendMessage to PostMesasge. The difference is whether you wait for the message to be processed.

Judy

Ganesh N. Paul13-Mar-07 5:12

Ganesh N. Paul

13-Mar-07 5:12

Hi have written an addin for the Outlook 2003. All in-coming mails are proparelly backup in the .Msg file at particular location on the disk. The objective of the saving the file in the .MSG format is that on double clicking on the .Msg file it will open in the MS Outlook, or even if we do drag and drop it will open in MS Outlook. The basic thing i want to do is to set passward to .Msg file for opening in MS Outlook. It should either ask for user name and password or any other strategy of authetication. Once it passes this user name and password it should open in MS Outlook, Help me...
Confused | :confused:

-- modified at 8:20 Wednesday 14th March, 2007

Ganesh Paul SPIAN

Memory debug window in VS2005

ilgale13-Mar-07 5:02

ilgale

13-Mar-07 5:02

Hi guys, I'm new in VS2005 and I can't find the Memory Window that I could open with "View->debug Windows->Memory" in VS6.
Where can I find that window ?
Thanks a lot

Re: Memory debug window in VS2005

Cedric Moonen13-Mar-07 5:05

Cedric Moonen

13-Mar-07 5:05

In "Debug" -> "Windows" -> "Memory" (only when you are debugging)

Cédric Moonen
Software developer

Charting control [v1.1]

DLL Question

Programm3r13-Mar-07 4:41

13-Mar-07 4:41

Hi all,

This might be a stupid question(s) but here goes:
Does a registered dll stay in memory?
And does a dll that doesn't need registered stay in memory?

Thanx in advance.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

CPallini13-Mar-07 4:53

CPallini

13-Mar-07 4:53

Naively, all kind of DLLs (registered and unregistered ones) are loaded in memory by the OS loader when a process needs to get linked with.

Standard DLLs (such as User32.dll) don't need registration, registration is required only by COM DLLs.

Hope that helps.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Programm3r13-Mar-07 4:58

13-Mar-07 4:58

CPallini wrote:
Hope that helps.

CPallini, yes it does help, thank you very much. But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)

Thanx for your reply.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

Cedric Moonen13-Mar-07 5:02

Cedric Moonen

13-Mar-07 5:02

Programm3r wrote:
But the other thing is after the function call will the dll still reside in memory? (Registered and those who don't need registration)

Which function call ?

In fact, you have two ways to load your dll. Either explicitely (by using LoadLibrary) or implicitely (you link to a library provided with the dll that contains information about how to load the dll's).
In the first case, the Dll is loaded when you call LoadLibrary and is released when you call FreeLibrary (if there is no other application that uses it). Or it is released when your application exits.
In the second case, the dll is loaded when your application is started an is released when your application terminates.

Cédric Moonen
Software developer

Charting control [v1.1]

Programm3r13-Mar-07 5:20

13-Mar-07 5:20

Cedric Moonen wrote:
Which function call ?

Thanx Cédric, you have already answered my question in your thread.
Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

Roger Stoltz13-Mar-07 5:10

Roger Stoltz

13-Mar-07 5:10

Registration of a DLL has nothing to do with when the DLL is loaded into the address space of the process that uses the DLL. Registration of a DLL is only needed if the DLL exposes a function called DllRegisterServer which usually is only applicable for COM DLLs.

Read more about DLL loading here[^].

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Programm3r13-Mar-07 5:22

13-Mar-07 5:22

Thank you very much Roger.

Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

CPallini13-Mar-07 5:16

CPallini

13-Mar-07 5:16

Programm3r wrote:
But the other thing is after the function call will the dll still reside in memory?

Oh YES, of course...

The OS loader may discard the DLL if the process detaches from. For an ordinary DLL, if the process implicitely links with (e.g. you have used the DLL's *.lib as input for the LINKER; this is the most common way...) the detaching happens on process termination; on the other hand, if the process explicitely links with (via LoadLibrary call), then the process can, at any time, discard the library by means of the corrensponding FreeLibrary call.

COM uses a completely different approach, a component DLL may be discarded by the COM when the component it's no more needed, i.e. when the reference count of the component reaches 0 (see life cycle of COM components in MSDN, however, basically, calling Release() on a COM pointer, allows COM to discard the related DLL).

Hope that helps
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Programm3r13-Mar-07 5:23

13-Mar-07 5:23

Thank sfor your help CPallini, really appreciate it.

Regards,

The only programmers that are better than C programmers are those who code in 1's and 0's..... Smile | :)

Programm3r
My Blog: ^_^

you're welcome.

CPallini13-Mar-07 6:10

CPallini

13-Mar-07 6:10

you're welcome.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

Eytukan13-Mar-07 6:59

Eytukan

13-Mar-07 6:59

Now tell me an MFCxx.dll is a COM dll or a standard DLL? Roll eyes | :rolleyes:

Press: 1500 to 2,200 messages in just 6 days? How's that possible sir?
Dr.Brad :Well,I just replied to everything Graus did and then argued with Negus for a bit.

toxcct13-Mar-07 8:01

toxcct

13-Mar-07 8:01

VuNic wrote:
Now tell me an MFCxx.dll is a COM dll or a standard DLL?

none. you have to provide it with your application binary, or place it in the path...

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]