C / C++ / MFC

Re: Why do functions in the C library have short names?

7-Sep-09 11:33

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.

Stuart Dootson7-Sep-09 14:45

Stuart Dootson

7-Sep-09 14:45

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

ID_FILE_NEW causes application crashed [modified]

transoft7-Sep-09 10:58

7-Sep-09 10:58

Hi
I want to run a dialog box doing some setting before I open a new MDI child. I did following:

BOOL CMyApp::InitInstance()
{
....

    // Don't display a new MDI child window during startup
    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()
{
////run dialog
   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

Richard MacCutchan7-Sep-09 11:36

7-Sep-09 11:36

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.

transoft7-Sep-09 16:58

7-Sep-09 16:58

Please note that:

void CMainFrame::CMFileNewSetting()
{
////run dialog
   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

Richard MacCutchan7-Sep-09 23:25

7-Sep-09 23:25

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?

SandipG 7-Sep-09 21:39

SandipG

7-Sep-09 21:39

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?
Confused | :confused:

[/edit]

Regards,
Sandip.

transoft8-Sep-09 2:12

8-Sep-09 2:12

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,

David Crow8-Sep-09 3:31

David Crow

8-Sep-09 3:31

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

transoft8-Sep-09 3:50

8-Sep-09 3:50

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()
{

......
	// The main window has been initialized, so show and update it.
	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,

David Crow8-Sep-09 3:55

David Crow

8-Sep-09 3:55

Since it blocks the message pump, using MessageBox() is rarely a good thing to use for debugging. Use TRACE() instead.

transoft8-Sep-09 4:24

8-Sep-09 4:24

OK, I will use TRACE(). Thanks.

The bug is not from "MessageBox". Even I deleted the "MessageBox". It crashed also.

Thanks,

Re: ID_FILE_NEW causes application crashed [modified]

David Crow8-Sep-09 4:35

David Crow

8-Sep-09 4:35

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.

transoft8-Sep-09 4:33

Resize an image without a Window

8-Sep-09 4:33

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

GeeBru7-Sep-09 10:48

GeeBru

7-Sep-09 10:48

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

Richard MacCutchan7-Sep-09 10:52

7-Sep-09 10:52

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.

GeeBru7-Sep-09 10:58

GeeBru

7-Sep-09 10:58

Ah silly me then Wink | ;-)

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.

Richard MacCutchan7-Sep-09 11:42

7-Sep-09 11:42

I'm not sure I understand how the pieces fit together in your description here, perhaps you could elaborate?

However, GDI+ operates on DeviceContexts 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?

Calling CFrameWnd::RecalcLayout causes slight flicker in left pane (CTreeView) of outlook style splitter app

Stuart Dootson7-Sep-09 14:50

Stuart Dootson

7-Sep-09 14:50

This library[^] provides image resizing without (as far as I'm aware) using windows or GDI facilities. You want either the Resample or Resample2 method[^].

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

Sternocera7-Sep-09 9:20

Sternocera

7-Sep-09 9:20

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

Re: Calling CFrameWnd::RecalcLayout causes slight flicker in left pane (CTreeView) of outlook style splitter app

Richard MacCutchan7-Sep-09 10:56

Re: Calling CFrameWnd::RecalcLayout causes slight flicker in left pane (CTreeView) of outlook style splitter app

7-Sep-09 10:56

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( Frown | :(

) from CView or similar?

Sternocera7-Sep-09 11:01

Sternocera

7-Sep-09 11:01

CFrameWnds may display views, or other CFrameWnds. They are, as the name suggests, for framing things.

Regards,
Sternocera

Re: Calling CFrameWnd::RecalcLayout causes slight flicker in left pane (CTreeView) of outlook style splitter app

Richard MacCutchan7-Sep-09 11:26