|
Hi,
Can I use DDX_CONTROL instead of create to connect my rich edit control defined in my resource file
thankx
|
|
|
|
|
As far as i can tell from what you wrote here, yes. (Althorough how you would use "create" to connect a member variable to a control defined in your resource puzzles me)
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Isn't the last parm on the ::create the resource id of the
control defined in the resource file I would think that connects it
to the specfic CWnd object
The reason I like DDX_CONTROL is that it would pick up
the demensions of window/control and I don't
have to figure out the values for the CRect
Thankx
|
|
|
|
|
As far as i know the last param of ::CreateWindow (or ::CreateWindowEx if that is what you mean) isn't what you think it is. However, you can use DDX_Control to attach a control variable to your rich-edit easily.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
And it will pick up all the pars from the resorce file
|
|
|
|
|
I'm not sure what you mean by that but probably yes.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Sorry for the delay in responding but had some religous holidays
what I meant was the deminsions of the edit control would be picked up from the resource file defination
plus the style bits e.g. ES_MMULTILINE
After DDX_CONTROL do I still have to a create though ??
thankx
|
|
|
|
|
Then i understood correctly. No, you do not need to create it, it is done for you when you create the dialog (directly by calling Create or indirectly by calling DoModal on the dialog itself), with DDX you simply attach the already exsisting control to your variable.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
When I went stepping thru the DDX_Control
The Cricheditctrl m_hWnd seemed to be intialized
I passed the DDX_Control my Myrichedit data memeber (think I am using the right term)
Since this a call by reference doesn't seem like I should need to do any more before using
the Richedit methods on this object
thankx again
|
|
|
|
|
hi ppl,
I got this framework which obiously includes windows.h... 
And I got a static library which includes afxwin.h.
I need afxwin.h because I want to use CCmdTarget class.
And I got this error: WINDOWS.H already included. MFC apps must not #include <windows.h>
I am not creating a MFC application and I need CCmdTarget class and I cannot remove windows.h... 
Any workarounds?? 
Thank you all.. 
|
|
|
|
|
The CCmdTarget class is part of MFC.
So you don't have the option of not using MFC.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
You can include all the MFC stuff first. This way, you can be sure that windows.h is already included for the framework that comes next.
But, like the other poster said, you are going to be building an MFC application.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I have been updating an MFC application that has the following line of code in it to create Edit Boxes (Note tmp is a CString object):
CreateEx(WS_EX_CLIENTEDGE, _T("EDIT"), _T(tmp), WS_CHILD | WS_TABSTOP | WS_VISIBLE, *pMyRects[0], pParent, resourceId);
Up until recently, this code has worked fine. On my latest build, only the Debug build works. The Release build crashes. I traced the crash to this particular line of code. The CreateEx function actually never returns. I can't debug it, since as I said the Debug configuration doesn't crash.
What's weird is when I replaced the _T(tmp) parameter with _T("") so the line looks like below, the Release build doesn't crash.
CreateEx(WS_EX_CLIENTEDGE, _T("EDIT"), _T(""), WS_CHILD | WS_TABSTOP | WS_VISIBLE, *pMyRects[0], pParent, resourceId);
I've googled this issue and can't find anything like it anywhere. Does anyone know if there is some issue passing a CString to the CreateEx function or if there's a problem because the CString was created locally in the function?
Another strange quirk is that I ran the Release executable on a machine with Vista (rather than XP which is what I am developing on) and the code doesn't crash.
|
|
|
|
|
Why are you using the _T() macro on a CString ? Try removing it and see if this fixes your problem.
|
|
|
|
|
Sorry, I didn't specify that before, originally I wasn't using the _T macro, I was just passing the CString by itself. That crashed the program too.
|
|
|
|
|
Did you try "tmp.GetBuffer()"?
|
|
|
|
|
Hadn't tried GetBuffer(), but tested it out and that crashed it too.
Strangly, setting up a local char * and passing it in works just fine too, it's just passing anything associated with the CString object.
|
|
|
|
|
How about following?
TCHAR tempString[...];
strcpy(tempString, tmp.Getbuffer());
CreateEx(, , tempString, ....
|
|
|
|
|
transoft wrote: TCHAR tempString[...]; strcpy(tempString, tmp.Getbuffer());CreateEx(, , tempString, ....
Nope, doesn't work either. What I can't understand is why this code existed in previous builds and now causes a problem, why it works in Vista, and why the Debug Configuration in XP also works. The whole executable is around 5000 lines of code plus a driver to a hardware card so the project isn't huge, but not tiny either. So I suppose it could be some strange interaction with memory somewhere or something with the stack.
|
|
|
|
|
There must be some reason.
Are you sure that "CreateEx" crashed your software? Like "strcpy" will also crash program because of temp string has not enough buffer.
Could you post your code here?
|
|
|
|
|
transoft wrote: e you sure that "CreateEx" crashed your software? Like "strcpy" will also crash program because of temp string has not enough buffer.
Could you post your code here?
No, I'm not positive that CreateEx is THE cause, all I know is that the
code crashes before the function ever returns. I had narrowed this down by putting Message Boxes throughout the code and the last one that successfully displayed was immediately before the CreateEx() call.
Here's the code that crashed:
void DialogEditBoxObject_Class::init(CWnd *pParent, CString ctrlText, UINT resourceId)
{
CString tmp;
tmp.Format("%d", nLimit); //nLimit is a class member
//pMyRects are allocated in the constructor and do exist here
CreateEx(WS_EX_CLIENTEDGE, _T("EDIT"), tmp, WS_CHILD | WS_TABSTOP | WS_VISIBLE, *pMyRects[0], pParent, resourceId);
CRect clientRect;
GetClientRect(clientRect);
pMyFont->CreateFont(clientRect.Height(),0,0,0,FONT_HEIGHT(700),0,0,0,
ANSI_CHARSET,OUT_DEFAULT_PRECIS,
CLIP_DEFAULT_PRECIS,
DEFAULT_QUALITY,
DEFAULT_PITCH|FF_DONTCARE,
"arial");
SetFont(pMyFont); //pMyFont was allocated in the constructor
}
|
|
|
|
|
Often when the debug version works and the release crashes and you're dealing with pointers, you might have an uninitialized pointer. The debug heap zeros data blocks before it returns them and the release version doesn't. The pointer value itself is nonNULL but contains garbage so when something dereferences it, the program crashes. If the function accepts NULL as a valid pointer, it obviously checks and doesn't try to dereference the pointer. Since it worked before, you may just have gotten lucky and the garbage in the pointer pointed to something that could be interpreted as a valid string.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Tim Craig wrote: Often when the debug version works and the release crashes and you're dealing with pointers, you might have an uninitialized pointer. The debug heap zeros data blocks before it returns them and the release version doesn't. The pointer value itself is nonNULL but contains garbage so when something dereferences it, the program crashes. If the function accepts NULL as a valid pointer, it obviously checks and doesn't try to dereference the pointer. Since it worked before, you may just have gotten lucky and the garbage in the pointer pointed to something that could be interpreted as a valid string.
Thanks, that's useful to know. I was imagining that it could be a memory problem somewhere. The code I inherited when I took this project over was awful; even the debug version was letting me know about numerous memory leaks. I wrapped most of the code in classes and cleaned up new/delete calls all over but it is possible there is a more subtle problem going on that the debugger isn't letting me know about.
|
|
|
|
|
I'm a french new MFC programmer, and at run-time (compiling is OK), I got a message from MSVC++. This message is a Debug Error(Value of ESP was not properly saved...Problem of convention function calling). It's seems I located the call function which generate this exception. Following a piece of my source code. I think it's a function declaration problem. Thank's if someone could help me.
class CRepository
{
{
struct Server {
struct AutomationModules {
int nDataValid;
char szFilename[20];
char szDrawrow1[50];
char szDrawrow2[50];
char szDateModifier[10];
};
char szServerName[20];
AutomationModules files [MAX_FILES];
int nValid;
};
public:
CString RepositoryName;
bool bModify;
Server server[MAX_SERVERS];
CRepository() {}
virtual ~CRepository() {}
.....
public:
void InverseServer(CRepository::Server *Svr1,CRepository::Server *Svr2);
...
};
CRepository *pRepository = new CRepository;
...
extern CRepository *pRepository
...
pCrepository->InverseServer(&server[j],&server[j+1]);
...
|
|
|
|
|
AntoineBab wrote: ...I got a message from MSVC++. This message is a Debug Error(Value of ESP was not properly saved...Problem of convention function calling).
Which statement is generating the error?
AntoineBab wrote: pCrepository->InverseServer(&server[j],&server[j+1]);
What is the value of pCrepository at this point?
"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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
