C / C++ / MFC

5-Nov-02 13:12

try "strlen" and its cousins.

-c

“losinger is a colorizing text edit control”
-- googlism

newbie needs help

kjessee5-Nov-02 13:05

5-Nov-02 13:05

Probably another simple queston.

I have used the same code in other dialog boxes, (with different variables)and it works.
Thanks for the help.

I get the following ASSERT at the line containing m_BeginStr.ResetContent();

_AFXWIN_INLINE void CComboBox::ResetContent()
{ ASSERT(::IsWindow(m_hWnd)); ::SendMessage(m_hWnd, CB_RESETCONTENT, 0, 0); }

void CDlgOffset::OnButtonBrowse()
{
FILE *StrFile;
CWnd* pWnd;
CString sStrName;
double E;
double S;

CFileDialog dlg( TRUE, "txt", NULL, OFN_FILEMUSTEXIST, "Text Files (*.txt)||\0" ,NULL );
int nResponse = dlg.DoModal();

if (nResponse == IDOK)
{
m_StrFile = dlg.GetPathName();
pWnd = GetDlgItem( IDC_EDIT2 );
pWnd->SetWindowText( m_StrFile );

// Load the Combo Boxes

StrFile = fopen( m_StrFile, "r+");
fseek( StrFile, 0L, SEEK_SET );

m_BeginStr.ResetContent();
m_EndingStr.ResetContent();

while( fscanf( StrFile, "%s %lf %lf", sStrName, &E, &S ) != EOF )
{
m_BeginStr.AddString( sStrName );
m_EndingStr.AddString( sStrName );
}

fclose( StrFile );
}

}

C^hris L^osinger5-Nov-02 13:08

5-Nov-02 13:08

has m_BeginStr been initialized? chances are that it isn't yet a "window" (and the ::IsWindow test is failing). make sure you're either DDX'ing the control or SubClassing it (ie. attaching an actual control to the variable)

-c

“losinger is a colorizing text edit control”
-- googlism

kjessee5-Nov-02 13:23

5-Nov-02 13:23

it has CCombobox attached to it in the member varibles.

C^hris L^osinger5-Nov-02 13:22

5-Nov-02 13:22

look in the DoDataExchange function of your dialog. do you see a line that looks something like this:

DDX_Control(pDX, IDC_MY_COMBOS_ID, m_BeginStr);

?

if not, it needs one. otherwise, the member variable is never actually attached to the control.

-c

“losinger is a colorizing text edit control”
-- googlism

kjessee5-Nov-02 13:39

5-Nov-02 13:39

It is there.

void CDlgO::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CDlgOffset)
DDX_Control(pDX, IDC_COMBO_END_STR, m_EndingStr);
DDX_Control(pDX, IDC_COMBO_BEG_STR, m_BeginStr);

C^hris L^osinger5-Nov-02 13:38

5-Nov-02 13:38

hmmm.

can you put a breakpoint on that DDX line and step into the DDX_Control code to see if anything fails?

-c

“losinger is a colorizing text edit control”
-- googlism

kjessee5-Nov-02 14:28

Really Annoying Novice Question

5-Nov-02 14:28

it fails before it gets there.

Kevin

ursus zeta5-Nov-02 12:41

ursus zeta

5-Nov-02 12:41

This question concerns the various C++ and corresponding header files that you would normally combine into a single project workspace folder. I'm somewhat mystified (but, I'm new to C++ and Visual C++,...everything is mysterious) as to the reasoning behind creating numerous separate files (both C/C++ and the definition headers) for a given project, except maybe convenience. As a novice to C++ programming, I find it much more educational to review the actual code than to read descriptive textbook style explanations of the various objects and functions. Currently, I am reading through Petzold's Programming Windows, which is excellent for a beginner like myself, but, I am curious as to why so many separate code files are necessary in a small, simple project as are presented in Petzold's book.
My main assumption is that for code and object re-use, it is convenient to have files that can be just added with an #include directive. I am wondering if in some circumstances it is preferred to have a definition header or series of such files for some specific configuration (I can't imagine what). Do I sound confused? I'm not even sure how to phrase to question.
Also, is it critical as to what order these various files are added to the project file? I am unclear as to what operations that compiler actually performs on these files besides scanning the syntax and creating a hierarchy of elements and instructions.
Anyone that could please just recommend an article that I could refer to, or a subject listing in the MSDN library, I would appreciate it hugely. Thanks.

C^hris L^osinger5-Nov-02 13:11

5-Nov-02 13:11

you mentioned both of the answers:

1. code resue. you can't really reuse a class in another project, if it's definition is hidden away in a .CPP somewhere.

2. convenience. if your project gets much past the HelloWorld stage, you'll start to end up with classes and modules that have logical distinctions. for your own sanity, it's best to move those into separate files to keep the parts as manageable as possible.

no, it the order in which you add them to the project doesn't matter. VC will scan them and determine the dependencies automatically so that they are built in the right order.

-c

“losinger is a colorizing text edit control”
-- googlism

ursus zeta5-Nov-02 13:20

ursus zeta

5-Nov-02 13:20

Chris,
Thanks. I thought it would be more complicated.

Paul M Watt5-Nov-02 13:40

Paul M Watt

5-Nov-02 13:40

First off, Petzold's "Programming Windows" is completely written in C. While C is very similar to C++ in syntax and many other features, it lacks support for classes and it treats structs slightly differently so be aware of this fact.

The include files are where you will generally define your consts, global functions, classes and such, and the CPP file is where you will implement them. By defining your code in an include file, you will be able to reference the things defined in the header in a number of different CPP files. This model also facilitates code re-use.

The only time that the include order is important for the header files is when a header file that is defined, depends on a previous header file being defined. Usually the header that depends on another header will include it itself, however there are cases where the order is important, especially if you use ATL.

It is actually the preprocessor that scans through the header files. In fact, the #include directive, directs the preprocessor to extract all of the text from the file that has been included, and insert that text in place of the #include directive. So you could picture all of the files that you include, as being inserted automatically for you as if you had pasted them there yourself. After the preprocessor runs, then the compiler goes through and compiles each CPP file individually.

Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!