|
There are many ways to doing it, as seen on this[^] link.
I recommend you first decide what path you want to take between these four Microsoft alternatives, then pick up some reference material on it and go from there.
- Win32 API - Lowest level, C-based API, ugly.
- MFC - Class library with great support from DevStudio. Thinly wraps many Win32 APIs. It's been around for years.
- WTL - Template based class library. Not well supported or widely used, but some people like it more than MFC.
- .NET - Shiny, new, easier. Natively supported by other languages such as C# and VB.NET. The wave of the future.
Regards,
Alvaro
Quitters never win. Winners never quit. But those who never win and never quit are idiots. -- despair.com
|
|
|
|
|
.NET - Shiny, new, easier. Natively supported by other languages such as C# and VB.NET. The wave of the future.
This stuff always cuts me up.
First there was C, then C++, then early Windows, then newer Windows, then MFC, then COM, then DCOM, then ATL, and now it's C# and .NET
I somtimes wonder, will I grow old before .NET is obsolete, or will it be obsolete before I can cut my next fart. <- potentially my new SIG
I somtimes wonder, will I grow old before .NET is obsolete, or will it be obsolete before I can cut my next fart.
|
|
|
|
|
Just put this in a .cpp file and compile :P
#include <windows.h>
LRESULT CALLBACK WindowProcedure(HWND, UINT, WPARAM, LPARAM);
char szClassName[ ] = "WindowsApp";
int WINAPI WinMain(HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nFunsterStil)
{
HWND hwnd;
MSG messages;
WNDCLASSEX wincl;
wincl.hInstance = hThisInstance;
wincl.lpszClassName = szClassName;
wincl.lpfnWndProc = WindowProcedure;
wincl.style = CS_DBLCLKS;
wincl.cbSize = sizeof(WNDCLASSEX);
wincl.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wincl.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
wincl.hCursor = LoadCursor(NULL, IDC_ARROW);
wincl.lpszMenuName = NULL;
wincl.cbClsExtra = 0;
wincl.cbWndExtra = 0;
wincl.hbrBackground = (HBRUSH) GetStockObject(LTGRAY_BRUSH);
if(!RegisterClassEx(&wincl)) return 0;
hwnd = CreateWindowEx(
0,
szClassName,
"Windows App",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
544,
375,
HWND_DESKTOP,
NULL,
hThisInstance,
NULL
);
ShowWindow(hwnd, nFunsterStil);
while(GetMessage(&messages, NULL, 0, 0))
{
TranslateMessage(&messages);
DispatchMessage(&messages);
}
return messages.wParam;
}
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, message, wParam, lParam);
}
return 0;
}
Ack i probably shouldnt promote this entire Copy-Paste behaviour huh?
Kinda VB-ish
Kuniva
--------------------------------------------
|
|
|
|
|
Wow. It worked. Thats pretty good. Where in the code would I put my message though? What would I write for it? (Im used to cout << "MESSAGE" << endl;) sort of thing...
|
|
|
|
|
change this:
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, message, wParam, lParam);
}
return 0;
}
to this:
LRESULT CALLBACK WindowProcedure(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_CREATE:
MessageBox (NULL, "Hello world!" , "test", 0 + MB_ICONASTERISK);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, message, wParam, lParam);
}
return 0;
}
So you see, just use the MessageBox() function to display a message...
the case WM_CREATE stuff is there because thats how u see what kind of message was posted to the message queu, WM_CREATE is posted when your window is created, so your message would display on startup...
Kuniva
--------------------------------------------
|
|
|
|
|
yES I SEe but when i did that it just popped up a little window with my message...i wish to put my message in the window that u already created.
|
|
|
|
|
i suggest u read ur book again
Kuniva
--------------------------------------------
|
|
|
|
|
|
That one did now work actually...i pasted and tried to compule it but im working in C++ and that was C so there was 5 errors....
|
|
|
|
|
Hey thanks to you all for your help. I did get it to work / Seems all i had to do was add this:
case WM_PAINT: hDC = BeginPaint(hwnd, &ps);
TextOut(hDC, 300, 100, "Hello, World!", 13);
EndPaint(hwnd, &ps);
Anyways thanks a lot and it looks like i dont have to go back to my book after all
|
|
|
|
|
I have a View class spawning a CDialog class (used the class wizard). If I include "View.h" in mydlg.h,
and include "mydlg.h" in view.h, i get bizarre errors which miraculouosly disappear if I comment out the #include "view.h" from the dlg class. BUt I wanted to use that .h file to access some info from the view class in the dlg. So I tried forward declare class myView but it doesnt like that either....
Appreciate your help,
ns
|
|
|
|
|
In your mydlg.h, put this:
class View; ( or CView, if that's it's name)
Then #include it in your mydlg.cpp file.
Christian
NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma
Anonymous wrote:
OK. I read a c++ book. Or...a bit of it anyway. I'm sick of that evil looking console window.
I think you are a good candidate for Visual Basic. - Nemanja Trifunovic
|
|
|
|
|
I think you mentioned that you already tried forward declarations, and that they didn't help.
You might try putting the following line in your .h file:
#pragma once
Otherwise, try playing with #ifndef using the (very long) names #define'd by the class wizard:
#ifndef MYDIALOG_AFX_LOTSA_STUFF_THAT_LOOKS_LIKE_A_GUID
#include "mydialog.h"
#endif
|
|
|
|
|
Did you try prototyping ?
Before you use a class into an other class you have to #include the header. If you only need a pointer to an other object, you can prototype this class. The compile knows the definition (pointer to a class) and the implementation is linked afterwards.
Wimel
-objectA.h-
class objectA;
class objectB
{
objectA* m_poA;
}
-objectB.h-
class objectB;
class objectA
{
objectB* m_poB;
}
|
|
|
|
|
Hi!
I have created an Application launcher and I use CreateProcess() to launch my Apps. My problem is that I cannot close my application launcher if my applications are not finished. Is there a way to make the Application launcher and the App independent so that can close my launcher after I have created my Apps?
Everything's beautiful if you look at it long enough...
|
|
|
|
|
I founded!
Just use ShellExecute( NULL,
"open",
m_Process,
NULL,
m_Path,
SW_SHOWNORMAL
);
Everything's beautiful if you look at it long enough...
|
|
|
|
|
Instead of using CreateProcess(), maybe you should use ShellExecute to launch your other applications.
CString filepath = "C:\\temp.exe";<br />
<br />
HINSTANCE err = ShellExecute(NULL, _T("open"), filepath , NULL, NULL, SW_SHOW);
It should look something like that, but my C++ has been getting a little rusty lately.
Hope that helps.
Daniel E. Blanchard
|
|
|
|
|
My mistake, you beat me to it.
Daniel E. Blanchard
|
|
|
|
|
Yes.
Try this:
// Run specified 32-bit process
bLaunched = ::CreateProcess(
pszPath, // name of executable module
szCommandLine, // program command line
NULL,
NULL,
FALSE,
CREATE_DEFAULT_ERROR_MODE | NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&si,
&pi
);
ShellExecute uses CreateProcess anyway, so you are just missing something or have a bad argument to the function.
C++/MFC/InstallShield since 1993
|
|
|
|
|
Hi there,
According to "Using a Doc/View exported from a dynamically loaded DLL (SDI)" article : http://www.codeproject.com/docview/SdiCViewDll.asp[^], I load Form Views from DLLs. Unfortunately, the View loading fails when the exported view contains Custom Controls and advanced controls such calendar, Rich Edit and so on.
Any idea ? Please help me
Thanks !!
|
|
|
|
|
Have you tried InitCommonControls[Ex], AfxInitRichEdit[2]?
Regards,
BB
|
|
|
|
|
Thank you for your answer BB, your advice is all right with rich edit control (with the use of AfxInitRichEdit), but the exported form view is still crashing with custom controls
An assert occurs on the view creation -> hWnd is NULL in CreateDlgIndirect(). I guess that something is not properly initialized but what ? That is the question, hopping that someone could answer to it...
After some searches, I didn't found anything interesting about such initialisation...
|
|
|
|
|
Following the initialization path, did you register your custom control classes in the DLL?
Regards,
BB
|
|
|
|
|
Effectively I didn't registered it. Since this custom control works when used in the main application, I was guessing that it would dirctly run.
I'm not very close to DLLs, can you quickly explain me how to register it and why it's needed ?
Thank you very much BB, I begin to see the light at the end of the tunnel
|
|
|
|
|
There's an important issue here: MFC extension DLLs maintain their own resource handle.
Personally I call such function in the C++ constructor of all my custom controls (I modified it slightly to fit your question):
BOOL CMyCustomCtrl::RegisterClass()<br />
{<br />
WNDCLASS wndcls;<br />
HINSTANCE hInst = AfxGetResourceHandle();<br />
<br />
if(!(GetClassInfo(hInst, "MyWndClassName", &wndcls)))<br />
{<br />
wndcls.style = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS;<br />
wndcls.lpfnWndProc = ::DefWindowProc;<br />
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;<br />
wndcls.hInstance = hInst;<br />
wndcls.hIcon = NULL;<br />
wndcls.hCursor = LoadCursor(NULL, IDC_ARROW);<br />
wndcls.hbrBackground = NULL;<br />
wndcls.lpszMenuName = NULL;<br />
wndcls.lpszClassName = "MyWndClassName";<br />
<br />
if(!AfxRegisterClass(&wndcls))<br />
{<br />
AfxThrowResourceException();<br />
return FALSE;<br />
}<br />
}<br />
return TRUE;<br />
}
The function checks whether the control is registered with current resource handle, and registers it if not yet done. This way we cover both the application and DLL case. The function can be universal if you derive your custom controls from the common base class and use "MyWndClassName" as a function argument.
You may read in the MSDN what the several WNDCLASS members mean, and the code is self-commenting I guess. I hope I didn't miss anything in this explanation, but ask if there's turn out wrong.
Regards,
BB
|
|
|
|
|