|
It probably was not intentional by K&R and early C developers, but short function names in the C standard library make sense. Like Huffman coding, the length of words that humans use are inversely proportional to their frequency. For example, "I" and "ventriloquist." Since standard-library functions are used more than the programmer's own functions, they are shorter.
|
|
|
|
|
The original C library was developed in the early days of UNIX when computers were slow and had very little storage to work with, and input/output devices that operated at fairly low speeds. In order to conserve space most library functions were named in six characters or less to prevent the compilers from taking forever to turn source into executable code. Because of that history many of the original names are still in existence.
|
|
|
|
|
C was developed as the system programming language for Unix. The C run-time library functions have LONG names compared to Unix shell commands....ls, rm, ps etc
In addition, I suspect there may have been a desire to keep identifier names short - when doing string comparisons, the worst-case time is O(N), so the smaller you make N (the string length in this case), the better. Remember, in 1970, a computer had much, much less processing power and storage bandwidth than your phone has these days...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi
I want to run a dialog box doing some setting before I open a new MDI child. I did following:
BOOL CMyApp::InitInstance()
{
....
if( cmdInfo.m_nShellCommand == CCommandLineInfo::FileNew )
cmdInfo.m_nShellCommand = CCommandLineInfo::FileNothing;
....
pMainFrame->ShowWindow(m_nCmdShow);
pMainFrame->UpdateWindow();
PostMessage(pMainFrame->GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW_SETING, (LPARAM)0);
return TRUE;
}
void CMainFrame::CMFileNewSetting()
{
PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}
The code runs OK while I try to launch the app within the VisualStudio. But when I tried to run the App.exe, App.exe crashed. After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.
How can I correct this problem?
Best regards,
modified on Monday, September 7, 2009 5:13 PM
|
|
|
|
|
transoft wrote: PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
You need to post the message to a HWND handle. Also note that PostMessage, of itself, does not run a dialog.
|
|
|
|
|
Please note that:
void CMainFrame::CMFileNewSetting()
{
PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}
"PostMessage" will post the message to "this" HWND.
This code runs OK when I run it in VisualStudio. But it crashed When I ran the app.exe.
Thanks
|
|
|
|
|
The code extracts seem to be different with every message you post. What exactly is the code that you think causes the crash (i.e. how do you know it is the PostMessage() call), and what are the values of the various parameters that are being processed. Are you sure that the code you run through the debugger is the same as in the app.exe that crashes?
|
|
|
|
|
transoft wrote: void CMainFrame::CMFileNewSetting()
{
////run dialog
PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
.....
}
Probably you should handle WPARAM and LPARAM for the above message even if you do not need them.
This will cause crash in release builds. I am not sure if app.exe is in release build. I hope it helps.
[edit]
I missed following
transoft wrote: After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.
You said you could run the exe properly using VS then how come you were able to reproduce the problem in VS?
[/edit]
Regards,
Sandip.
|
|
|
|
|
It would not crash in VS. I can not find where the problem code located.
The debug version of code (app.exe) will crash also if running outside VS.
I think might be the location of my postmessage( ...,ID_FILE_NEW, ); where cause the problem.
Thanks,
|
|
|
|
|
transoft wrote: I want to run a dialog box doing some setting before I open a new MDI child.
This sounds like a splash screen.
transoft wrote: After debugging, I found out that "PostMessage( WM_COMMAND, ID_FILE_NEW, (LPARAM)0);" cause the App.exe crashed.
What is a crash?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
Hi
The App.exe did not give me any hints. When I tried to use JIT debugger to find the bug, JIT debugger seems hanging there. It looks like stuck in a never end loop.
I tried following coide
BOOL CSignApp::InitInstance()
{
......
pMainFrame->ShowWindow(m_nCmdShow);
pMainFrame->UpdateWindow();
MessageBox(NULL, "test", "test", IDOK);
PostMessage(pMainFrame->;GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW, (LPARAM)0);
return TRUE;
}
I did two tests. I put "MessageBox(NULL, "test", "test", IDOK);" before and after "PostMessage(pMainFrame->GetSafeHwnd(), WM_COMMAND, ID_FILE_NEW, (LPARAM)0);"
If the MessageBox was added before PostMessage, "MessageBox" will show. After will not.
Where is the good place for sending "ID_FILE_NEW" message?
Best regards,
|
|
|
|
|
Since it blocks the message pump, using MessageBox() is rarely a good thing to use for debugging. Use TRACE() instead.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
OK, I will use TRACE(). Thanks.
The bug is not from "MessageBox". Even I deleted the "MessageBox". It crashed also.
Thanks,
|
|
|
|
|
transoft wrote: The bug is not from "MessageBox". Even I deleted the "MessageBox". It crashed also.
I'm aware of that. The suggestion was not meant to resolve your problem.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
I used wizard to create a new MDI project and added same things in the new MDI. It works just fine.
I think I did something wrong before I PostMessage.
It is very hard to find this type of bugs.
Thanks,
modified on Tuesday, September 8, 2009 10:45 AM
|
|
|
|
|
Is it possible to resize an image using something like GDI+ without using MFC or Win32. If so does anyone have any examples?
Thanks in advance
|
|
|
|
|
GeeBru wrote: Is it possible to resize an image using something like GDI+ without using MFC or Win32.
Well since GDI+ is part of Win32 then I think the answer is probably 'No!'. Maybe it would be better to try and explain what you are trying to achieve, and why.
|
|
|
|
|
Ah silly me then thanks for the quick reply.
What I need to do is shrink a JPG by calling a C function as I have a different application that calls C functions from within a DLL and I'm unsure how to go about creating the function. As the application cannot pass windows handles etc then I wondered if GDI+ could do it without needing that kind of thing.
Thanks.
|
|
|
|
|
I'm not sure I understand how the pieces fit together in your description here, perhaps you could elaborate?
However, GDI+ operates on DeviceContext s rather than Windows, so as long as you can instantiate a DC you can do all the GDI+ing necessary. Whether you do this in C, C++, C# or any other language is largely your own choice.
GeeBru wrote: As the application cannot pass windows handles
Any reason why not?
|
|
|
|
|
|
Hello,
I'm writing an MFC app that is in the style of MS outlook, with a CTreeView in the left hand pane, and a CFrameWnd, called CRightPaneFrame, that contains a view (which view varies, depending on which node on the CTreeView is selected) - a splitter application.
In the function that switches views, called by the CTreeView, the final thing we do is call RecalcLayout(), to have everything (re)drawn. This causes slight, although noticeable flicker in the left pane, as the Main frame of the application is (apparently) redrawn.
How can I prevent this flicker from occurring, by limiting redrawing to CRightPaneFrame and its current CView? According to MSDN, RecalcLayout is "Called by the framework when the standard control bars are toggled on or off or when the frame window is resized". This seems like overkill for this task (updating CRightPaneFrame/its underlying view). How all can I accomplish this task without redrawing my left pane?
Regards,
Sternocera
|
|
|
|
|
I think perhaps your naming gives it away - CRightPaneFrame! CFRameWnd (if memory serves) should be used for the Frame window which holds all the other child windows that your app needs to display. Have you tried deriving your right pain( ) from CView or similar?
|
|
|
|
|
CFrameWnds may display views, or other CFrameWnds. They are, as the name suggests, for framing things.
Regards,
Sternocera
|
|
|
|
|
Thanks, it's a while since I used MFC, but I always thought that CFrameWnd was the main window and comprised the actual frame, plus the menu etc, which would not work properly in a child window.
|
|
|
|
|
Hello,
Is there a way to get the certificate of a seucre web page that is
currently being displayed using CWebBrowser?
Thank You..
|
|
|
|