|
I have walked through SetPath and I have stepped through FileSaveys. The values are exactly the same. I don't know what's going on; I just know that it is not doing as it is supposed to. I believe everything you are telling me Mark. Believe me that the error message is telling me my path is wrong when I KNOW it is the same. Or the debugger is lying to me. It's there and it's correct!. I took the same path and created a different CString varable, placed it into that CString's constructor and there was no problems. If you woul, use my class and create a file-path by adding CStrings together and see it that works on your machine. Again I've checked SetPath, and at the very point that I transfer what str has in it, to the public CString varable m_csFileName is correct. m_csFileName shows in the debug as to have received the correct path. in SetPath. it also shows the correct path in FileSaveSys right up to the Open STATEMENT. I can hardcode this path. But what worries me is the actual filename I will be lokking for in the future may not be there. m_csIsFileName will be unique and I won't know it's name because the program created that name by adding the date and time to the end of the m_csWellName. "SystemDB.sdb" is only a practice/proveable file for testing the ability of the program to work correctly to that point. If the well name was Murphy13 and the date was Jan 12, 2008 the time the User called for the file is: 11:02am, the filename would be "Murphy13011220081102.ddb". But I won't know anything about that! That's why this part must work correctly, and I can't get my CStrings to coopporate.
A C++ programming language novice, but striving to learn
|
|
|
|
|
Hi,
I've added a toolbar in a dialog based project following
what's written in this page:
http://www.codeproject.com/KB/dialog/dialog_tips.aspx[^]
The project already has a menu bar so in the toolbar I've set
the same ID for buttons having a corresponding menu item.
Now the situation is the following:
when I push toolbar buttons the application calls automatically
the callback associated to the right menu item but...
I don't know how to let the toolbar buttons be enabled or disabled
according to menu items (ON_UPDATE_COMMAND_UI).
How can I solve this problem?
Thanks a lot.
|
|
|
|
|
|
Currently, I am working on a GUI for video surveillance-object detection using MFC and is rather unfamiliar in using the MFC. I wonder if anyone here would able to give me some advice for source code for the following:
1) Using a dialog-based application in C++6.0, how do I capture live video from the webcam to the dialog box itself (i.e. picture control) using OpenCv (without using directshow)? I should be able to click on buttons created and the livevideo will start/pause/stop on the dialog box(i.e. picture control).
For now, I am thinking of this method whereby I follow the below link to create the picture control and let it draw the bmp file.
http://www.codeguru.com/cpp/g-m/bit...icle.php/c4939/
This implies that I need to convert the opencv's ipl file to mfc's bmp file and deal with multiple images so as to provide realtime images. Thinking of using a 'for' loop to perform the capturing of multiple images, but would like to ask if you have any better suggestions?
2)As I will need to store the bmp files to be processed for object recognition when I press the "InitializeDetector" button created, I would like to ask if anyone knows how to create a framegrabber? How do I store the files for image processing?
Please advise.
Thanks in advance! 
|
|
|
|
|
|
I have this existing MFC application. I'd like some external C#/Silverlight application to communicate with it. Does anyone know how to add code so it can act as web service? Any pointer to articles / sample is welcome!
Thanks in advance!
|
|
|
|
|
|
ohhh you are being harsh ... I know roughly a web service is. But true not that much. I know it's stateless and that you can pass it some SOAP command...
What I want to do is provide an API to my MFC application... some way of communicating between a web app and my app... A web service seemed a good idea - do say if I am wrong!
|
|
|
|
|
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"...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
