|
OK, here's the deal. I'm writing this program, and it creates a couple of edit boxes on a dialog. Now I'm ready to attach variables to these edit boxes, but when I try to do this I keep getting an error when the program executes. If I put the edit boxes on the dialog with the resource editor and then attach variables with Class Wizard everything is fine, but if I try to attach the variables myself without Class Wizard the program doesn't work. Anyone know what I'm doing wrong?
|
|
|
|
|
When you say "it creates a couple of edit boxes on a dialog" what exactly do you mean?
|
|
|
|
|
What I mean is that I added a couple of CEdit member variables to the dialog class and then called the Create() method on them in the dialog's OnInitDialog() function.
|
|
|
|
|
OK, I'm with you so far. Now when you say "attach variables to these edit boxes", how, when, and where are you doing that?
|
|
|
|
|
OK, let me see if I can clear this up. If I'm going to use Class Wizard what I would do is after I've added the control to the dialog I'd start class wizard. I'd go to the Member Variables tab, click on the ID of the edit control and click the Add Variable button. This would create a variable and link it to the edit control so that I could call UpdateData() to send and recieve the text of the control.
That explains what I'm trying to do now I'll tell you how I've been trying to do it. I added a member variable to the dialog, initialized it in the dialogs constructor, and then added a line like
DDX_Text(pDX, IDC_EDIT1, integer);
to DoDataExchange(). IDC_EDIT1 is the control ID and integer is the variable that I'm trying to link to it. As far as I can tell this is exactly what Class Wizard does.
|
|
|
|
|
First, as Mr. Dunn, has pointed out we would need the error message to know for sure, I would wager that what your getting is an assertion and if you go to the point of the assertion it is complaining about an hwnd not being valid or something to that affect.
I would think maybe that the problem is that DoDataExchange is getting called before you actually create the controls themeselves in OnInitDialog.
I would suggest you do this, if you have not already done it, put a break point in DoDataExchange, and one in OnInitDialog. Start the dialog, see which one the app reaches first.
I will confess that I have never tried to do things quite the way you describe, I kind of like the "Visual" part of "Visual C++". I would be interested to found out whats happening.
|
|
|
|
|
Actually, I've found that this is exactly what is happening. Good analysis, thanks.
|
|
|
|
|
You said you're getting an error message. What error? What does GetLastError() return?
--Mike--
http://home.inreach.com/mdunn/
We've secretly replaced the msdn.microsoft.com servers with Atari 800XLs. Let's see if anyone notices....
|
|
|
|
|
Well, I'm not sure exactly how to use GetLastError(), but when I run the debugger I'm take to the lines
TRACE1("Error: no data exchange control with ID 0x%04X.\n", nIDC);
ASSERT(FALSE);
I would assume this means the the control ID I'm using in
DDX_Text(pDX, IDC_EDIT1, integer);
isn't linked to the control yet. I'm thinking that if I use GetDialogItem() to get a pointer to the control and then test to make sure it isn't NULL this ought to fix it, hopefully.
|
|
|
|
|
The trace message is saying there's no control in the dialog with an ID of IDC_EDIT1. Fix the ID in the DDX_Text() line.
--Mike--
http://home.inreach.com/mdunn/
We've secretly replaced the msdn.microsoft.com servers with Atari 800XLs. Let's see if anyone notices....
|
|
|
|
|
Actually, the problem is that the control isn't created until OnInitDialog() is called. DoDataExchange() is called first, before the control has been created.
|
|
|
|
|
In your OnInitDialog() function, first create the controls, then call CDialog::OnInitDialog(). CDialog::OnInitDialog calls DoDataExchange().
---
Multitasking: Screwing up several things at once.
|
|
|
|
|
DoDataExchange is called once before OnInitDialog, to update the controls.
I suppose you have to Create your control in OnCreate, not in OnInitDialog.
Hope it works,
Paolo.
|
|
|
|
|
Just out of curiousity, and to be in no way critical of your design, why are you doing things this way? Are you just experimenting to learn how things work (which is commendable), do you have some philosophical issues with doing things visually (which is debatable), or are you just trying to create controls that you can work with dynamically at runtime? (i.e. something derived from CEdit which has extended functionality). If the later is the case, I could suggest other techniques to you which you might find easier to use, as well as being safer to use within the MFC model.
|
|
|
|
|
I was wondering when someone would ask why I was doing things this way. There are many easier ways to accomplish what I'm doing. I'm just experimenting.
|
|
|
|
|
In an attempt to be cool, I am putting a Slider control into a toolbar. The only problem: registering slider events.
I know that a slider sends its parent a WM_HSCROLL message, but in this case the parent is just a toolbar. Is there a way for my CMainFrame (which owns the toolbar, naturally) to receive the event?
thanks,
Jake
|
|
|
|
|
|
More respect towards VC
Here bad words cannot be said.....
An expression from my country.
It does not give the head you?
Cheers!!!
Carlos Antollini.
|
|
|
|
|
Speaking of VC++ and how much it sucks, I've got some issues with the debugger. Has anyone, in the history of the universe, found it helpful when the debugger points to a line of "disassembly" code to point out your error? The value of that debugging technique is completely lost on me, and I was wondering how it helps anyone. Otherwise, VC++ could be worse.
|
|
|
|
|
It certainly leaves a lot to be desired in many ways. But I would hate to write a large, complex windows app without it! If you had been around pre-1993 trying to put together a large windows app (not a little in-house job that VB is for) you would appreciate it more.
|
|
|
|
|
Yes, this is often extremely helpful. Learning a little asm will be well worth your time.
Oh, and the VC++ debugger is pretty good, for user mode programs at least. What have you used that's any better??
|
|
|
|
|
SoftICE
-Ben
---------
On the topic of code with no error handling -- It's not poor coding, it's "optimistic" 
|
|
|
|
|
it helps sometimes if i'm doing low-level optimizations. but, i could easily get along without it. benchmarking is usually a better way of telling which tricks are faster.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
Well, perhaps ppl, like experts use it.
|
|
|
|
|
John Robbins excellent book 'Debugging Windows' tells you how to figure what line of code you crashed on using the disassembly window. It also tells you how to write crash handlers and lots of cool stuff. It's not just about how to push F10 and F11 in the debug Window ( like the useless 'Desigining user interfaces' book, has anyone actually *bought* that. No weait, don't tell me. ).
Anyone who doesn't have this book should buy it.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
