|
Nope. AfxBeginThread is declared in afxwin.h , which is a part of MFC framework.
In Win32 apps, use _beginthread instead.
Regards,
BB
|
|
|
|
|
Win32 apps should use _beginthreadex , not _beginthread.
|
|
|
|
|
Both may be used, however _beginthreadex is better (security information, initial state, autoclosing handle, etc.). Thanks for your comment.
Regards,
BB
|
|
|
|
|
Hey Friends I Have Created an MDI Application in which I Want that on Click of a Button All Windows Should Close.
I Have Used CFrameWnd as the FrameWindow.
I Know of CWinApp::CloseAllDocuments(BOOL) but it do not Closes these Windows ?
PL Help.
|
|
|
|
|
Check out the CDocTemplate::CloseAllDocuments function.
Regards,
BB
|
|
|
|
|
Hi ppl
well my problem is with explicit linking here.Actually there is this function called
"SetLayeredWindowAttributes" that i want to link explicitly following is the code:
typedef BOOL (CALLBACK*LPFNSETLAYEREDWINDOWATTRIBUTES)(COLORREF,BYTE,DWORD);
...
BOOL CMainFrame ::TranparentWindow()
{
HINSTANCE hDLL; // Handle to DLL
LPFNSETLAYEREDWINDOWATTRIBUTES lpfnSetLayeredWindowAttributes; // Function
pointer
COLORREF color = RGB(100,100,100);
BYTE alpha;
DWORD what;
hDLL = LoadLibrary(_T("USER32.DLL"));
if (hDLL != NULL)
{
lpfnSetLayeredWindowAttributes =
(LPFNSETLAYEREDWINDOWATTRIBUTES)GetProcAddress(hDLL,"SetLayeredWindowAttributes");
if (!lpfnSetLayeredWindowAttributes)
{
// handle the error
FreeLibrary(hDLL);
return FALSE;
}
else
{
// call the function
BOOL status;
status = lpfnSetLayeredWindowAttributes(color,alpha,what);
}
}
}
I am calling this function on the OnCreate message handler there are no linker
problems as well when the program is executed it gives me an error regarding ESP
tellimg me something about conflicting calling conventions anyone having any idea wats
the problem here please do tell me
Thanks in advance
Ahmed ajmal
|
|
|
|
|
You're missing an argument from the prototype for SetLayeredWindowAttributes :
BOOL SetLayeredWindowAttributes(
HWND hwnd,
COLORREF crKey,
BYTE bAlpha,
DWORD dwFlags
);
Software Zen: delete this;
|
|
|
|
|
Hi !!
What is the meaning of following statements:
#if _MSC_VER > 1000<br />
#pragma once<br />
#endif // _MSC_VER > 1000
generated by visual studio in header files.
|
|
|
|
|
It tells the compiler to only process the header file once.
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
As Taka said, it tells the compiler to process the header file only once
(unlike the usual #ifndef _HEADERNAME #define _HEADERNAME ..., it doesn't need to open the file again, start parsing etc.)
It's implemented only in certain compiler versions, for which is the additional #ifdef _MSC_VER check
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
I want to use my own dialog as a base for another one. Don't want to copy anything from the base dialog, just construct it and ready.
Someone confuses me by advising I have to add/change a constructor. I tried his way (adding UINT nId) as good as I've understood him. But seems to be not good enough. I think I'm making mistakes with the dialog id. I was told to remove the "enum {IDD...}" line. I don't understand.
What do I have to do in my base dialog and what in the derivated dialog (.h + .cpp)?
This is my code which does NOT construct the derivated dialog:
***MyBaseDlg.h***
// Two constructors
CMyBaseDlg (CWnd* pParent = NULL); // Not used by the derivated Dialog
CMyBaseDlg (UINT nIDTemplate, CWnd* pParent = NULL); // Use this one
*** MyBaseDlg.cpp***
CMyBaseDlg:: CMyBaseDlg (CWnd* pParent /*=NULL*/)
: CDialog(CMyBaseDlg::IDD, pParent)
{
}
CMyBaseDlg:: CMyBaseDlg (UINT nIDTemplate, CWnd* pParent /*=NULL*/)
: CDialog(nIDTemplate, pParent)
{
}
Derivated Dialog: class CSecondDlg : public CMyBaseDlg
***SecondDlg.h***
CSecondDlg(UINT nID, CWnd* pParent = NULL);
***SecondDlg.cpp***
CSecondDlg:: CSecondDlg (UINT nIDD, CWnd* pParent /*=NULL*/)
: CMyBaseDlg (nIDD, pParent)
{
}
Call the derivated dialog somewhere in my code:
CSecondDlg dlg(CMyBaseDlg::IDD); // How to call correctly?
Thanks,
Oli
|
|
|
|
|
Here it goes:
CMyBaseDialog::CMyBaseDialog(UINT IDD, CWnd* pParent )<br />
: CDialog(IDD, pParent)<br />
{<br />
}<br />
<br />
CSecondDlg::CSecondDlg(CWnd* pParent )<br />
: CMyBaseDialog(CSecondDlg::IDD, pParent)<br />
{<br />
}<br />
<br />
CSecondDlg dlg;
Naturally, the "embedded" IDD should only be contained in CSecondDlg (it is not absolutely required, but helpful for ClassWizardry and such stuff).
Regards,
BB
|
|
|
|
|
Hi,
How can I use the GetDecryptionExponent function with RSAES_OAEP_SHA_Decryptor ?
This is really important for me, thank you
|
|
|
|
|
You are more likely to get help on Crypto++ by posting to their mailing list.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
the qusetion is at:
http://www.codeproject.com/listctrl/xlistctrl.asp?forumid=3227&fr=101&select=478331&df=100#xx478331xx
|
|
|
|
|
Hi All.
I am having with a toolbar rendering it'self when its created. It doesn't display the buttons except when I run my mouse over them. they all work as far as letting the application know its working..
here is the code I am using.. as you can see Its all in win32..
Hope somebody can help.. I can supply more code if needed..
Cheers
Chris
void JumpmanEditor::CreateSideBar()<br />
{<br />
RECT rc;<br />
GetWindowRect(m_hWnd, &rc);<br />
<br />
m_hWndTopBar = ::CreateWindowEx(0,<br />
"JumpmanStaticChild",<br />
"",<br />
WS_VISIBLE | WS_CHILD,<br />
0,
0,
rc.right - rc.left,
TOOLBAR_HEIGHT,
m_hWnd,<br />
NULL,
g_hInst,<br />
0);<br />
<br />
m_hWndTopBarScroll = ::CreateWindowEx(0,<br />
"JumpmanStaticChild",<br />
"",<br />
WS_VISIBLE | WS_CHILD | WS_HSCROLL,<br />
(TOOLBAR_BUTTON_SIZE + 2) * (TBCOUNTMAIN-1),<br />
0,<br />
rc.right - rc.left,<br />
TOOLBAR_PALETTE_HEIGHT + SCROLL_HEIGHT,<br />
m_hWndTopBar,<br />
NULL,<br />
g_hInst,<br />
0);<br />
<br />
m_hWndToolbarMain = CreateToolbar((TBBUTTON *)g_tbbuttonMain, TBCOUNTMAIN, m_hWndTopBar, TOOLBAR_BUTTON_SIZE, TRUE);<br />
m_hWndToolbarPalette = CreateToolbar((TBBUTTON *)g_tbbuttonPalette, TBCOUNTPALETTE, m_hWndTopBarScroll, TOOLBAR_PALETTE_BUTTON_SIZE, FALSE);<br />
<br />
palettescroll = 0;<br />
SetScrollPos(m_hWndToolbarPalette, SB_HORZ, palettescroll, TRUE);<br />
<br />
ShowWindow(m_hWndToolbarPalette, SW_SHOWNORMAL);<br />
ShowWindow(m_hWndToolbarMain, SW_SHOWNORMAL);<br />
}<br />
<br />
<br />
<br />
HWND JumpmanEditor::CreateToolbar(TBBUTTON *p_tbbutton, int count, HWND hwndParent, int size, BOOL text)<br />
{<br />
#define MAXRESLEN 128<br />
<br />
int i;<br />
HWND hwnd;<br />
<br />
hwnd = CreateToolbarEx( hwndParent,<br />
WS_CHILD | TBSTYLE_FLAT,
1,<br />
count,<br />
g_hInst,<br />
IDB_TOOLBAR,<br />
p_tbbutton,<br />
count,<br />
24,
24,<br />
24,<br />
24,<br />
sizeof(TBBUTTON));<br />
<br />
SendMessage(hwnd, TB_SETEXTENDEDSTYLE, 0, TBSTYLE_EX_DRAWDDARROWS);<br />
<br />
int foo;<br />
<br />
if (text == TRUE)<br />
{<br />
char szBuf[MAXRESLEN];<br />
<br />
for (i=0;i<count;i++)<br />
{<br />
LoadString(g_hInst, p_tbbutton[i].dwData, szBuf, MAXRESLEN-1);<br />
szBuf[lstrlen(szBuf) + 1] = 0;
foo = SendMessage(hwnd, TB_ADDSTRING, 0, (LPARAM) szBuf);<br />
}<br />
}<br />
<br />
SendMessage(hwnd, TB_SETBUTTONWIDTH, 0, (LPARAM)(DWORD)MAKELONG(size,size));<br />
<br />
for (i=0;i<count;i++)<br />
{<br />
TBBUTTONINFO tbbi;<br />
tbbi.cbSize = sizeof(tbbi);<br />
tbbi.dwMask = TBIF_SIZE | TBIF_COMMAND | TBIF_STATE | TBIF_STYLE;<br />
foo = SendMessage(hwnd, TB_GETBUTTONINFO, p_tbbutton[i].idCommand, (LPARAM)&tbbi);<br />
foo = SendMessage(hwnd, TB_SETBUTTONINFO, p_tbbutton[i].idCommand, (LPARAM)&tbbi);<br />
}<br />
<br />
SendMessage(hwnd, TB_AUTOSIZE, 0, 0);<br />
<br />
return hwnd;<br />
}<br />
|
|
|
|
|
Hi, everyone!
I ofter heard from others that the place where to define
a friend function of a class depend on whether the
client code is supposed to call that function or not. But
in my experience I always define the friend function in
.h file. I simply want to know what means "whether the
client code is supposed to call that function or not".
Can you give me an example?
regards,
George
|
|
|
|
|
Dude, you seem to hear a lot of things from others!
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Thanks, Taka buddy!
I like to hear and read experience by experienced
people. For example, programming experience. But
for a newbie, some experiences are too beief without
an example. For example, something like "10 rules of
...". So I just want to let experienced people to tell
me what they are talking about.
regards,
George
|
|
|
|
|
No problems
So, where did you hear this? Friends are *always* defined in the class definition which is usually going to be in a header file.
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Thanks, Taka buddy!
If you have ever studied how the compiler is working,
you will see what is my trouble. Suppose functionA is defined
in a header file. The compiler will recognize functionA as
valid identifier in any translation unit that includes A.h.
The function has external linkage by default. So I think if
a function is not called by others, it will be a waste to
define the function in the header file. Define it in .cpp
file is just OK. Since compiler external linkage will make
my program larger. But I do not know whether I am correct.
Can anyone help?
regards,
George
|
|
|
|
|
Defining a function in a header simply tells the compiler that the function exists (somewhere else) and has the specified signature.
You need to do it so that the compiler won't flag an error when you try to use it. That's all. If you don't call that function, it won't make your EXE bigger.
Declaring it in a CPP file is *wrong* since it is easy to change the signature of the function and forget to update the other declarations. If you have it in a single place i.e. the header file, you are more likely to get it right. If you are using a C++ compiler, name-mangling means that the linker is likely to flag an error but it's still bad practice.
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Thanks, Taka buddy!
Your reply has answered most of my questions. Now I
have a last question, can you show me a case
where the client code is not supposed to call that
function but we must define the function in .cpp file
and better not in .h file? I can not imagine that case.
regards,
George
|
|
|
|
|
Hello George,
Since MS introduced MC++ they've been promoting inline function definitions for classes. This renders the need for a separate header file a mere formality and thus some people actually avoid using header files.
But if you are planning on writing some global fucntions then it might be a darn good idea to keep them in a separate header file.
Regards,
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Thanks, Nishant buddy!
When you say inline function. Do you mean define a
function inside the .h file?
What means "This renders the need for a separate header
file a mere formality and thus some people actually
avoid using header files" in your reply? Why people avoid
using that way? Can you show me an example?
regards,
George
|
|
|
|
|