|
Probably not. This subject might not be optimal for a forum based tutorial. You will probably need to read some documentation on a few things like the WSDL Utility. WSDL.exe[^] is a utility that comes with the .NET Platform SDK, and Developing WebServices for IIS using Visual Studio.
When you give WSDL.exe the URL to your WebService (asmx) file on IIS. It will generate a C# source code file. The class generated in that file will derive from System.Web.Services.Protocols.SoapHttpClientProtocol.
led mike
|
|
|
|
|
I am still having problems creating an application using menus. I created a dialog based application that has an embedded dialog in the main dialog. The embedded dialog contains two tabs, one tab displays a dialog showing temperature readings (among other things), the other tab displays database values.
I placed a menu on the main dialog. When I select celsius from the menu of the main dialog I want the celsius value to display on one of the embedded dialogs. I have tried different strategies, but none seem to work. I tried to use the ON_COMMAND function, but I am not getting any results. My code works if I put buttons on the embedded dialog, however, I want to use the menu resource instead of buttons.
Specifically, I select celsius from the menu of the main dialog, I want the raw units currently displayed in the embedded dialog to be changed to celsius values. Any suggestions will be appreciated.
Thanks
Trevy
|
|
|
|
|
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 */
}
}
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
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.
"
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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...
-- modified at 8:20 Wednesday 14th March, 2007
Ganesh Paul SPIAN
|
|
|
|
|
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
|
|
|
|
|
In "Debug" -> "Windows" -> "Memory" (only when you are debugging)
|
|
|
|
|
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..... 
Programm3r My Blog: ^_^
|
|
|
|
|
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.
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.
|
|
|
|
|
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.....
Programm3r My Blog: ^_^
|
|
|
|
|
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.
|
|
|
|
|
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.....
Programm3r My Blog: ^_^
|
|
|
|
|
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
|
|
|
|
|
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.....
Programm3r My Blog: ^_^
|
|
|
|
|
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
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.
|
|
|
|
|
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..... 
Programm3r My Blog: ^_^
|
|
|
|
|
you're welcome.
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.
|
|
|
|
|
Now tell me an MFCxx.dll is a COM dll or a standard DLL?
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.
|
|
|
|
|
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...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
