|
Don't be so lazy, have you heard of google ?
|
|
|
|
|
|
You've just gotta love good old Wikipedia.
Steve
|
|
|
|
|
|
Hello,
Thanks for all your replies.You people are really great and this site really helps me in completing my project.
I hope to answer some of the questions for this site in future.
Right now I just participate passively.
Bye
Prithaa
|
|
|
|
|
I glad you found your answer
|
|
|
|
|
I need to make a dialog in MFC non-movable. There is no property like there is one for Visual Basic. How can it be done?
|
|
|
|
|
modal, or non-movable ? because these are definitely not same !
if you want the later, then check in the dialog editor the style property...
|
|
|
|
|
Changes in style property (popup, overlapped and child) does not seem to affect. What does affect is if the title bar is removed. But we need to have title bar. VB forms can be made non-movable only by setting one property. Is there any corresponding property in Dialogs in MFC?
|
|
|
|
|
but hey, you're not in VB, so don't try to stick to that easy language.
i have a question though. why would you need a title bar if you don't want it to be movable ?
|
|
|
|
|
Have a look at WM_WINDOWPOSCHANGED.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
This event gets the new position. But I am unable to find a way to change it or affect the position changing. If new position is pushed into the position structure it is not accepted. Is there a known solution to this problem?
|
|
|
|
|
Handle the WM_NCHITTEST message.
Check the reply from the base class call and if it is HTCAPTION then return HTNOWHERE;
See below
UINT CNchittestDlg::OnNcHitTest(CPoint point)
{
UINT nReply;
nReply = CDialog::OnNcHitTest(point);
if (nReply == HTCAPTION)
{
nReply = HTNOWHERE;
}
return nReply;
}
|
|
|
|
|
Thanks, it works excellently.
|
|
|
|
|
Hi
In a standard SDI mfc project, when I add .cpp and .h files to it by right clicking the project and using "Add files to Projec" option,those new file names are not shown in the "class names" combo box under "message maps" tab of Mfc class wizard.
Can you please tell me the reason for it?
With Regards
Neeraj Sinha
|
|
|
|
|
Hi Friends,
I m having a simple win32 console Application. It is running in a infinite loop, there is only one option to close application by clicking the close button in console. I want to trap this event when closing application.
Please suggest the best solution.
Thanks
Pankaj Jain
|
|
|
|
|
|
Thanks! I m looking.............
Pankaj Jain
|
|
|
|
|
The syntax of C++ has changed so dramatically???
--
======
Arman
|
|
|
|
|
Yes, it's called
C++
++
now
|
|
|
|
|
I want to know how I would be able to run 2 or more MFC apps within one single MFC Window. The purpose of doing this is to enable the user to run one or more MDI applications in one single Window.
The user should be able to select or attach other MFC applications ( all of which are MDI Window applications ) at initialisation. Once he selects the front ends, the parent application should find the executable files of the selected apps and then launch the child windows of those apps, within its own primary Window.
My question is, how would this be possible ? I have heard that .net allows you to host MFC apps within its own, but I do not intend to work on .net solutions. Ive heard OLE is a suitable workaround for this too, but is there any easier approach ?
thanx in advance,
looking forward to a prompt reply.
|
|
|
|
|
You can't do this with regular Win32 apps because you can't have windows from different processes in the same stack. You could try making the main frame an ActiveX control container, then write the other apps as AX controls.
|
|
|
|
|
You can do it. Run the following twice. The first instance creates a main window and the second a child within the first. If you use Spy you'll see that both windows belong to different processes. OLE relies on this feature of Win32 to implement in-place editing with out-of-process servers. Some messages should not be sent across processes (such as WM_NOTIFY) so obviously the window would have to be written to take this into account. In real world applications using edit controls as I’ve done is probably not sensible if parent notification is required, but using them simplifies the example code.
===========================================
// RunTwice.cpp : Defines the entry point for the application.
//
#include "stdafx.h"
#pragma data_seg(".shared")
HWND s_hMainWindow = NULL;
#pragma data_seg()
#pragma comment(linker, "/SECTION:.shared,RWS")
WNDPROC g_pSuper;
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_NCDESTROY:
PostQuitMessage(0);
break;
}
return CallWindowProc(g_pSuper, hwnd, uMsg, wParam, lParam);
}
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
if (s_hMainWindow==NULL)
{
s_hMainWindow = CreateWindow(
"EDIT", "Main",
WS_VISIBLE | WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | ES_MULTILINE,
0, 0, 500, 500,
NULL,
NULL,
hInstance,
NULL
);
LONG res = SetWindowLong(s_hMainWindow, GWL_WNDPROC, reinterpret_cast<LONG>(&WindowProc));
g_pSuper = reinterpret_cast<WNDPROC>(res);
}
else
{
HWND hChild = CreateWindow(
"EDIT", "Child",
WS_VISIBLE | WS_CHILD | WS_BORDER | ES_MULTILINE,
100, 100, 300, 300,
s_hMainWindow,
NULL,
hInstance,
NULL
);
LONG res = SetWindowLong(hChild, GWL_WNDPROC, reinterpret_cast<LONG>(&WindowProc));
g_pSuper = reinterpret_cast<WNDPROC>(res);
}
MSG m;
while (GetMessage(&m, NULL, 0, 0))
{
TranslateMessage(&m);
DispatchMessage(&m);
}
return 0;
}
Steve
|
|
|
|
|
|
Thanx Im looking into your suggestions.
|
|
|
|