|
BadJerry wrote: do say if I am wrong!
I can't say and wasn't saying a Web Service is the wrong solution.
BadJerry wrote: ohhh you are being harsh
I'm not being harsh, the reality of what it takes to have a Web Service might be harsh but I didn't invent them. 
BadJerry wrote: I know roughly a web service is. But true not that much.
Well then I guess you better get to reading eh? That Wiki page has a bunch of links at the bottom. Should keep you busy for quite a while. Good luck
led mike
|
|
|
|
|
Hi, Jerry.
You're looking at a multi part solution. First, create a new C# Web Service project in Visual Studio. If you're comfortable with C#, writing the web service code is pretty straightforward. Just be sure to keep the member functions public and use the [WebMethod] tag for the routines you want to make publicly available via the service.
After you've created your web service, go to your C++ app and in the Solution Explorer of Visual Studio, add a Web Reference pointing to your web service (you'll get a dialog prompting you for services in this project, on local host, or a remote url).
This web reference creates a C++ proxy class header file. You can then use this class in your C++ app to talk to the web service API. You'll need to use BSTRs instead of CStrings, etc., but by looking at the proxy header file the params will be obvious to you.
I don't have any ready articles to point you to, but if you search for them on each of the steps I've mentioned, you should find plenty of starter code to get you going.
Hope this helps,
|
|
|
|
|
Hi Christopher,
Thanks for your input. Yes I have managed to create a Web Service in C# in the past and it is straightforward. But what I want to do is the other way round. I would like a C# application or silverlight or whatever to communicate with my MFC application (a big mother who acts a bit like a service). I want to provide an API to this MFC app in other words. In the past, I would have used a COM object but I'd like something more future proof - hence a web service.
The web service would have methods to check the state of the MFC app or to request the app to do something.
That's it... and I am wondering about which architecture I should go for.
Any advise welcome!
Jerry
|
|
|
|
|
I'm not sure that a web service is really a relevant solution for what you're looking to do. Sounds more like you're looking for an appropriate choice for inter process communications.
Since the MFC app is doing all the heaving lifting and you have .NET apps that you want to talk to it, COM is actually a reasonable solution (I can't believe I just called COM reasonable). Alternatively, you could set up communication through sockets or named pipes (haven't tried accessing shared memory yet in the .NET world.
Trying to force this into a web service architecture just because it's the current trendy thing is rarely a good idea froma technical point of view. Of course, resume enhancement is another matter entirely.
|
|
|
|
|
Not too much thinking of my resume but yes, I am trying to get out of my comfort zone... and I'd like the app to have a zingy Silverlight front end 
And if it's a web service it means it's easier to document and for other programmers to be involved rather than named pipes or sockets... a bit more OO...
Thanks again for your advices!
|
|
|
|
|
Well, if you have your heart set on a web service, then probably the best approach is to expose functionality in the MFC app via COM and have the web service act as an intermediary, making COM calls to MFC and passing the results back to the caller of the web service. I don't see any reason why that shouldn't work for you.
Have fun!
|
|
|
|
|
Yes that's the direction we're going towards I think... I simply it won't be too slow. If it proves to of any interest for the community, I'll report back. Keep watching this column!
Ta!
|
|
|
|
|
Surely I'm missing something basical, but I cannot understand why both MessageBoxes are shown by the following code (inside the WndProc of hWnd Window)
case WM_TIMER:
{
static int iCounter = 0;
static int iAnswer = IDCANCEL;
iCounter++;
if (iCounter==10)
{
iAnswer = MessageBox(hWnd, _T("MsgBox A"), _T("MsgBox A"), MB_YESNO);
}
else if ( iCounter==12)
{
MessageBox(hWnd, _T("MasgBox B"), _T("MsgBox B"), MB_YESNO);
}
}
break;
I was expecting MsgBox B not shown until MsgBox A termination.
Could someone please clue me in on what's happening? (i.e. plz plz urgent help  )
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
MessageBox creates a window which has its own WndProc but it does not keep your previous WndProc to be called otherways the underlaying would never be repainted ...
|
|
|
|
|
OK, but what happens exactly? I mean, the main thread isn't waiting for MessageBox returning a value? If it is an asynchronous call, how is iAnswer set, at the end?
(When MessageBox is called for MsgBox B the value of iAnswer is still IDCANCEL).
BTW Thanks for your reply.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
The main thread (it is not a thread by the way ) will create a modal loop something like that:
// While the user has not pressed OK or Cancel or clicked one of the button
MSG msg;
while (::PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}
So the system never stops running... while you wait for the answer messages are still read from the "OS" and sent to the relevant windows. am I making sense?
|
|
|
|
|
BadJerry wrote: The main thread (it is not a thread by the way )
I think it is.
BadJerry wrote: So the system never stops running... while you wait for the answer messages are still read from the "OS" and sent to the relevant windows. am I making sense?
Yes.
Hence (roughly speaking) the main thread looses its quantum while waiting for iAnswer and possibly regains it to handle the next WM_TIMER message?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
OK yes there is a main thread but there is no secondary thread... it just feels that way.
If you look at the WinMain, you will see that there is message loop. When you create a modal dialog, you simply create another message loop . The same function can therefore be called twice but it's more like recursion than multithreading...
I hope this helps!
|
|
|
|
|
I got it, thanks.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
i created a dll....that uses the function..
headerfile
#ifndef _DLL_H_
#define _DLL_H_
#if BUILDING_DLL
# define DLLIMPORT __declspec (dllexport)
#else /* Not BUILDING_DLL */
# define DLLIMPORT __declspec (dllimport)
#endif /* Not BUILDING_DLL */
DLLIMPORT LRESULT CALLBACK KeyboardProc(int nCode, WPARAM wParam, LPARAM lParam);
#endif /* _DLL_H_ */
cpp file
/* Replace "dll.h" with the name of your header */
#include "key.h"
#include <windows.h>
DLLIMPORT LRESULT CALLBACK KeyboardProc(int nCode, WPARAM wParam, LPARAM lParam)
{
//some code here.....
}
BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,
DWORD reason /* Reason this function is being called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
MessageBox( NULL,"Test working","cool",MB_OK | MB_ICONINFORMATION);
break;
case DLL_PROCESS_DETACH:
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
}
/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
when im compiling this dll with Dev-C++ compiler..im getting error....
my compiler log is:
Compiler: Default compiler
Building Makefile: "D:\devcpp project\keylogger\testlogger\sysproc\Makefile.win"
Executing make...
make.exe -f "D:\devcpp project\keylogger\testlogger\sysproc\Makefile.win" all
g++.exe -c dllmain.cpp -o dllmain.o -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include" -DBUILDING_DLL=1
In file included from dllmain.cpp:2:
key.h:10: error: `LRESULT' does not name a type
make.exe: *** [dllmain.o] Error 1
Execution terminated
can someone please help me what im doing wrong...what im able to understand is that it is not able to get the declaration for LRESULT......
how to correc that.....
thanx in advance...dudes
|
|
|
|
|
You need to post the code from key.h as that's where the error is, probably on line 9 or 10. The chances are that key.h is being included before windows.h and the compiler therfore has no definition for LRESULT. LRESULT doesn't just magicallly exist it is defined by a typedef somewhere within the include tree of windows.h
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
You guys rock...amazing....i didn't even notice that key.h is included before windows.h.....i understand the concept very well...but its just that i forget to notice that...thanx...."MR. C++ GURU"...
|
|
|
|
|
Member 4449040 wrote: key.h:10: error: `LRESULT' does not name a type
Have you omitted a #include?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
i push the print screen key and the screen captures. then i run the executable file of the program i made. the program will be in such a fashion that it will get the captured screen from the memory and saves it on the hard drive. like u do from mspaint.
plz help me
|
|
|
|
|
|
|
when pressing the "print-screen" key, the OS will copy a bitmap of the screen on the CLIPBOARD in a bitmap format (probably CF_BITMAP).
your job, if you accept it, is to get the data back from the clipboard, create an image format (whatever it is) and
save it back on the disk in the format you want (easier is bmp).
There must be tooooonnnsss of examples of that on the web, just use google.
|
|
|
|
|
|
Umair Hakeem Zuberi wrote: how to get the image from clipboard in c
A link has already been provided to you. Why have you failed to read it? 
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
