|
How to enlarge/set the memory for a MFC project in VC6 platform?
In my MDI project, I set several dialogs , and some controls(such as check box)
after I add variable for each MFC control, successed in compiler no matter debug or release mode, then execute it and error occurs.
if delete some variable of the MFC controls, it might be ok.
I debuged the project, the error message "memory is not enough" is occurs in system function
LRESULT AFXAPI AfxCallWndProc(CWnd* pWnd, HWND hWnd, UINT nMsg,
WPARAM wParam = 0, LPARAM lParam = 0)
admire
|
|
|
|
|
is there a way to change the background color of these? and i have a slider that is created after the dialog is opened that needs to be changed to.
|
|
|
|
|
Use this if it suits your needs:
In the WM_CTLCOLOR :
HBRUSH hBR=CreateSolidBrush (RGB(255,0,0));
if(pWnd->GetDlgCtrlID ()== IDC_SLIDER1)
return hBR;
if(pWnd->GetDlgCtrlID ()== IDC_SCROLLBAR1)
return hBR;
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
that worked very well but i guess i messed up the scrollbar is part of a listctrl not just a scrollbar. and 1 of my sliders is created after i push a button and i dont know how to change its color.
if (m_Video == NULL)
{
m_Video = MCIWndCreate(this->GetSafeHwnd(),
AfxGetInstanceHandle(),
WS_CHILD | WS_VISIBLE | MCIWNDF_NOMENU,temp1);
}
that makes the slider.
-- modified at 22:51 Tuesday 20th June, 2006
|
|
|
|
|
The ScrollBar are derived from CScrollBar,So u can subclass it at runtime and return the brush in the WM_CTLCOLOR.I have never tried just an sugesstion .
Regards,
FarPointer
Blog:http://farpointer.blogspot.com/
|
|
|
|
|
locoone wrote: is there a way to change the background color of these? and i have a slider that is created after the dialog is opened that needs to be changed to.
HBRUSH CtestMFCDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if(nCtlColor== CTLCOLOR_SCROLLBAR)
{
hbr=CreateSolidBrush(RGB(0,100,0));
}
return hbr;
}The above code changes the Back color of all the scroll bar controls of the Dialog box.
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
Any one have the Coding convention guidelines for VC++?
Give me one, please.
Thanks
|
|
|
|
|
Here's one of mine:
Never use C-style casts in a C++ program; use the new C++ casting operators such as static_cast instead. Using C style casts, such as "(CWnd*)", is reckless, vague and dangerous.
Steve
|
|
|
|
|
Here's some code I developed recently which justifies my previous post and shows one of the ways C-style casts can go wrong. See if you can spot the problem. Hopefully this will educate the people who voted good advice down - the new style casting operators were not invented for fun but to solve real problems. As I said, this is just one example - the C-style cast, while it looks simple, is actually very subtle.
--------------------------------
// CastProblems.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "Classes.h"
#include "Actions.h"
int main(int argc, char* argv[])
{
Derived d;
GetBase2(&d)->Who();
return 0;
}
// Actions.h
//
#ifndef __ACTIONS_H__
#define __ACTIONS_H__
class Base1;
class Base2;
class Derived;
const Base2* GetBase2(const Derived *pDerived);
#endif // !__ACTIONS_H__
// Actions.cpp
//
#include "StdAfx.h"
#include "Actions.h"
//#include "Classes.h"
const Base2* GetBase2(const Derived *pDerived)
{
return (const Base2*)pDerived;
// return static_cast<const Base2*>(pDerived);
}
// Classes.h
//
#ifndef __CLASSES_H__
#define __CLASSES_H__
#include <iostream>
class RootBase
{
public:
void Who() const
{
using namespace std;
cout << "Base" << m_Num << endl;
}
protected:
RootBase(int num) : m_Num(num) {}
int m_Num;
};
class Base1 : public RootBase
{
public:
Base1() : RootBase(1) {}
};
class Base2 : public RootBase
{
public:
Base2() : RootBase(2) {}
};
class Derived : public Base1, public Base2
{
public:
};
#endif // !__CLASSES_H__
--------------------------------
As it stands this program will output "Base1" but we wanted "Base2". Needless to say if you use the following version of "Action.cpp" which uses "static_cast" the runtime error becomes a compiler error and your compiler complains instead of your customers.
--------------------------------
// Actions.cpp
//
#include "StdAfx.h"
#include "Actions.h"
//#include "Classes.h"
const Base2* GetBase2(const Derived *pDerived)
{
// return (const Base2*)pDerived;
return static_cast<const Base2*>(pDerived);
}
Steve
|
|
|
|
|
You can go here:
http://www.cs.rice.edu/~dwallach/CPlusPlusStyle.html
Heres another:
http://www.possibility.com/Cpp/CppCodingStandard.html
I personally find that coding convention changes as you work on different projects because different companies have different coding conventions. I personally use something like this:
LPSTR lszLogFile;
string strLogFile;
int iNumber;
void myFirstFunction(string)
{<blockquote>
For my php projects, as well as my own C++ projects that I work on with others I use this convention for commenting function definitions:
void outputString(string strOutputVal, int iIterations)
{<blockquote>for(int i=0; i<iIterations; i++)</blockquote><blockquote>{</blockquote><blockquote><blockquote>cout << strOutputVal << endl; </blockquote></blockquote><blockquote>}</blockquote>}
Hope that helps!
Robbie
-- modified at 0:21 Tuesday 20th June, 2006
|
|
|
|
|
capricious_001 wrote: void myFirstFunction(string){
//Here is my function definition
}
I hate this style; it's hard to visually see scopes. I prefer this:
void myFirstFunction(string)
{
}
Using this style makes it clearer which braces match (because they actually line up).
Steve
|
|
|
|
|
ooo yes thats what I meant to put. For some reason I cant indent when im in the <pre> tags
|
|
|
|
|
Which layout style is the best for my code?<br />
Such style issues are a matter of personal taste. Often, opinions about code layout are strongly held, but probably consistency matters more than any particular style. Like most people, I'd have a hard time constructing a solid logical argument for my preferences. <br />
I personally use what is often called "K&R" style. When you add conventions for constructs not found in C, that becomes what is sometimes called "Stroustrup" style. For example: <br />
<br />
class C : public B {<br />
public:<br />
// ...<br />
};<br />
<br />
void f(int* p, int max)<br />
{<br />
if (p) {<br />
// ...<br />
}<br />
<br />
for (int i = 0; i<max; ++i) {<br />
// ...<br />
}<br />
}<br />
<br />
This style conserves vertical space better than most layout styles, and I like to fit as much as is reasonable onto a screen. Placing the opening brace of a function on a new line helps me distinguish function definition from class definitions at a glance. <br />
Indentation is very important. <br />
<br />
Design issues, such as the use of abstract classes for major interfaces, use of templates to present flexible type-safe abstractions, and proper use of exceptions to represent errors, are far more important than the choice of layout style.
Regards,
FarPointer
Blog:http://farpointer.blogspot.com/
|
|
|
|
|
I do this one:
if( x == y ){
x = x + 1;
}
Because I have had too many entry-level programmers do this to the code...
if( x == y )
z = x + 1;
{
x = x + 1;
}
When the brace is on the end of the line, they almost never insert an extra line of code between the if and the opening brace!
And completely bollox up the logic. And sometimes these are the types of bugs I have spent DAYS trying to find. Needles to say, this is a trivialization for purposes of the sample. The error in logic on production code is not always so readily spotted.
I've seen better runs in my shorts! - Patches O'Houlihan
|
|
|
|
|
Does anyone know about the Nuts and Bolts of Exception Handling? How do I create a try/catch block from assembler, How does the Runtime Binary maintain Compile time Info, such as the type of the object that was thrown as an exception. Is this Compile Time info liable to change as a result of O/S upgrades?
LateNightsInNewry
-- modified at 21:13 Monday 19th June, 2006
|
|
|
|
|
|
I am trying to write an MFC application (Visual C++, on Windows XP) that calls QueueUserAPC(). But the compiler just says:
error C2065: 'QueueUserAPC' : undeclared identifier
Can someone show me an example of an MFC application's include files that runs this function please ..........
I have tried including winbase.h, and setting/unsetting things like _WIN32_WINNT, but nothing seems to work.
cheers,
Neil
|
|
|
|
|
neilsolent wrote: I have tried...setting/unsetting things like _WIN32_WINNT...
How?
This compiles fine:
#define _win32_WINNT 0x500
#include <windows.h>
void main( void )
{
QueueUserAPC(0, 0, 0);
}
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks. Yes your code does compile, but it is not an MFC application with the MFC headers. i.e. The following doesn't compile (project created with VC++ Wizard - console application that supports MFC - with your lines added)...
#include "stdafx.h"
#define _win32_WINNT 0x500
#include <windows.h>
void main( void )
{
QueueUserAPC(0, 0, 0);
}
The stadfx.h seems to screw it up....
Any ideas?
cheers,
Neil
|
|
|
|
|
There's no need to include windows.h when using MFC as the Afx header files do this automatically. All you need to do is define _WIN32_WINNT before any files get included by the preprocessor.
"The largest fire starts but with the smallest spark." - David Crow
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Yes, that's the kind of thing I've been trying ... but it still doesn't seem to work.
I have tracked the problem down to this include statement:
#include "winsvc.h"
If I comment this include out (it comes straight after #include "stdafx.h"), the compiler can resolve QueueUserAPC() (but obviously loads of other code doesn't work then!)
Thanks for all your help so far .....
cheers,
Neil
|
|
|
|
|
Sorry ignore that last message ... that was rubbish
What you said last time is correct. Silly me
cheers,
Neil
|
|
|
|
|
Hi All
I wonder about the reason that after create and use some com pointer ( Smart pointer ) why we must call delete of the current pointer ?
I know that the reason is to save memory - but if we does not delete the pointer the application will be crash.
So some one can tell me why the application will crash in case we did not delete the pointer ??
Thanks for any help. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
|
If you are talking about the COM Smart pointers, then you dont have to call a delete on it and we cant delete a com object as it is CoCreated rather new'ed.
its distructor will take care of releasing active interaces. Once all active interfaces are released the component class objuect will get released automatically, and once all the component class objects are unloaded, the component itself will get unloaded.
Only thing qe need to do is to call Release() on the COM interface. But if it is a Smart pointer you dont have to do that, smart pointer distructor will take care of this. Thats why its smart pointer.
cheers...milton kb.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
