|
I do not no how to create graph in c++?????????
|
|
|
|
|
Have you tried doing any research for samples or articles?
Use the best guess
|
|
|
|
|
Skinning cats comes to mind.
Steve
|
|
|
|
|
You have several options. Two of them are:
- (The hard way) Use graphics primitives (provided, for instance by
GDI or GDI+) to draw yourself the graph on the screen. - Use a graph control (or a graph library).
Veni, vidi, vici.
|
|
|
|
|
u have two ways to create graph in C++
u can use windows api,SDK(firstly,register window class,then create the window)to create
or u can use MFC to create graph
|
|
|
|
|
In my project, a batch file should be first started to launch cmd windows, as well as initializing some parameters and some background processes. in the cmd windows,my own calculation processes could be started by typing the exe name directly. Now, i've written a MFC application program, and want to implement my calculaiton processes in a dialog button. I want to use ShellExecute where the first paramter is the cmd window handle i've got. Can anybody tell me how to write the shellexexute to post a command line to an existing cmd windows.
many thanks.
|
|
|
|
|
The only method I know is creating a child process with redirected input and output. An example can be found in the MSDN: Creating a Child Process with Redirected Input and Output[^]. But I'm not sure if this can be also done with the command shell itself.
Another option is changing your design to use a master application instead of the batch file that starts all necessary processes where the master application and the processes use some kind of Interprocess Communications[^].
|
|
|
|
|
many thanks, i'll try it. 
|
|
|
|
|
Why I can't catch CMainFrame::OnLButtonDblClk in CMainFrame ?
void CMainFrame::OnLButtonDblClk(UINT nFlags, CPoint point)
{
TRACE("Hello\n");
CMDIFrameWnd::OnLButtonDblClk(nFlags, point);
}
I can't see any trace ... Why ?
Thank you.
|
|
|
|
|
From the WM_LBUTTONDBLCLICK entry in the MSDN:
Quote: Posted when the user double-clicks the left mouse button while the cursor is in the client area of a window. If the mouse is not captured, the message is posted to the window beneath the cursor. Otherwise, the message is posted to the window that has captured the mouse.
The message is probably send to a child window of your main frame window (e.g. a view window).
|
|
|
|
|
Well, I would like to catch double-click message on CMainFrame when I haven't any childs open, and on non-child area of CMainFrame.
modified 10-Apr-13 3:00am.
|
|
|
|
|
Does your child view class include CS_DBLCLKS in its specification?
Use the best guess
|
|
|
|
|
No, I think he hasn't, because I had tried that on a default MDI application ...
|
|
|
|
|
U can catch the click in view class
because the message is posted to the CView class by the framework ,not the CMainFrame class
|
|
|
|
|
And when I didn't have any child open ?
|
|
|
|
|
Hello Friends
I am creating a mfc based application which is working fine on WinXP But If I run same application on Win7 then while Starting,a whilte image is appearing and disappearing[ like a white flash image].
But,If I Disable "Enable desktop Composition" option under system dialog named performance Options.Then it is not showing any white flash image.
After that I tried to Disable this option programmatically even,it does but then it fluctuating the screen while startup of application as we are disabling on initializing of application.
So, Any ideas to get rid of this white flash image.
Regards
Y
|
|
|
|
|
Which tools(IDE) did u used created the MFC Application?
applications that created by vc6.0 is not compatible to win7.
I Guess.
|
|
|
|
|
Get the following run time error after making a few changes in my MFC application. Not been able to find where it occurs other than when I click on the OK button of the Main Dialog.
This may be due to a corruption of the heap, which indicates a bug in MFCTest.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while MFCTest.exe has focus.
The output window may have more diagnostic information.
HEAP[MFCTest.exe]: Invalid Address specified to RtlValidateHeap( 003C0000, 003C8E70 )
Windows has triggered a breakpoint in MFCTest.exe.
This may be due to a corruption of the heap, which indicates a bug in MFCTest.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while MFCTest.exe has focus.
The output window may have more diagnostic information.
Object dump complete.
Any suggestions to how to locate this heap problem?
I think I deleted the OK button and then tryied to undo the changes.
grahamfff
|
|
|
|
|
Do you have a handler for the OK button? If so, what's in it?
Does the problem happen when you click the Cancel button?
You mentioned "Main Dialog." Are other dialogs involved?
Does this happen with a basic application, or only after you add other code to it?
Are you linking with other libraries?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
It happens after all the code in the OnBnClose() has run.
I deleted the Cancel button a long time ago.
The are other modal dialogs but they are OK. I think I got confused when I deleted the OnOK() routine and tried to reinstate it. It is using IDOK as a resourse.
Its a big MFC application and I deleted some controls and control variables but seemed to have got in a mess. I can usually sort things out, but this time because its at the program termination phase I am a bit lost as nothing to bebug.
grahamfff
|
|
|
|
|
It's possible the memory corruption is happening way before your OnOK handler is being called; it's just being detected there.
Calling this: http://msdn.microsoft.com/en-us/library/y1132dee%28v=vs.80%29.aspx[^]
at various times will help to localize where this is happening.
Another approach is the Binary Chop Debugging Pattern: Comment out portions of your program and rerun. If the problem remains, the bug isn't in the removed code. This debugging pattern can sometimes localize the bug orders of magnitude faster than trying to find it logically.
Visual Studio 6 had a way to invoke afxCheckMemory () after each operation, which is slow but will find the memory bug when it happens. I haven't seen this facility on later VS versions, though.
|
|
|
|
|
Try enabling the "page heap" for the process. Remember to turn it off when you're done debugging.
Steve
modified 9-Apr-13 2:31am.
|
|
|
|
|
But with the AfxCheckMemory() I get the following, puting the statement in InitDlg() routine.
Again do not understand.
ntdll.dll!7c90120e()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7c96ee31()
ntdll.dll!7c95f8f4()
ntdll.dll!7c96e94d()
ntdll.dll!7c96f586()
ntdll.dll!7c962fcf()
user32.dll!7e418bd9()
user32.dll!7e41885a()
user32.dll!7e42a013()
user32.dll!7e43e577()
user32.dll!7e42a998()
user32.dll!7e43e577()
> mfc90d.dll!CWnd::DefWindowProcA(unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 1043 + 0x20 bytes C++
mfc90d.dll!CWnd::Default() Line 274 C++
mfc90d.dll!CDialog::HandleInitDialog(unsigned int __formal=723394, unsigned int __formal=723394) Line 673 + 0x8 bytes C++
mfc90d.dll!CWnd::OnWndMsg(unsigned int message=272, unsigned int wParam=723394, long lParam=0, long * pResult=0x0013e2dc) Line 2018 + 0x11 bytes C++
mfc90d.dll!CWnd::WindowProc(unsigned int message=272, unsigned int wParam=723394, long lParam=0) Line 1755 + 0x20 bytes C++
mfc90d.dll!AfxCallWndProc(CWnd * pWnd=0x0013e7b4, HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 240 + 0x1c bytes C++
mfc90d.dll!AfxWndProc(HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 403 C++
mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 441 + 0x15 bytes C++
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42927b()
user32.dll!7e42651a()
user32.dll!7e42683e()
user32.dll!7e439b43()
mfc90d.dll!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x00480aa0, CWnd * pParentWnd=0x00000000, HINSTANCE__ * hInst=0x00400000) Line 312 + 0x2a bytes C++
mfc90d.dll!CDialog::DoModal() Line 576 + 0x20 bytes C++
MFCTest.exe!CMFCTestApp::InitInstance() Line 63 + 0xb bytes C++
mfc90d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00161f0a, int nCmdShow=1) Line 37 + 0xd bytes C++
MFCTest.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00161f0a, int nCmdShow=1) Line 30 C++
MFCTest.exe!__tmainCRTStartup() Line 574 + 0x35 bytes C
MFCTest.exe!WinMainCRTStartup() Line 399 C
kernel32.dll!7c81776f()
grahamfff
|
|
|
|
|
The problem has already occurred before your app explodes. The page heap will tell you more, but it probably happens in CMFCTestApp::InitInstance (or something called from there) but before the call to DoModal.
B
Steve
modified 9-Apr-13 17:08pm.
|
|
|
|
|
Thanks for all who posted.
But as I cannot get a handle on the problem which may be due to using an existing MFC application for a simular one. I deleteled some controls and renamed some of the dialogus and classes (including files names) and seem to have done something that has resulted in the basic framework failing.
Perhaps the Close button problem was a 'red herring' and perhaps best to start again and copy over code snipps as could spend ages on this problem and get nowhere. I always found it difficult to reuse an MFC application.
I have checked butons, textboxes dropdown lists etc and the resourses and event handlers but still the problem remains.
grahamfff
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
