whats wrong here

Code:

---

        CString tmp;
        vector <CString> eachword;
        int i;

        //split the thing up into words
        for(i=0;i<=txtSource.StringLength(txtSource);i++){
                //MessageBox(txtSource.Mid(i,1));        //debug
                if(txtSource.Mid(i,1)==' '){
                        eachword.push_back(tmp);
                        tmp.Empty();
                } else{
                        tmp+=txtSource.Mid(i,1);
                }
        }
 
                eachword.push_back("ignorethis");

        for(i=0;i<=eachword.size();i++){
                MessageBox(eachword[i]);
        }

---

this is my first time doing windows programming. its to split up each word in a sentence

suppose txtSource="hello how are you"

the message box will output

hello
how
are
ignorethis
[crashes]

or if i take out "ignorethis"
hello
how
are
[crashes]

if you change the sentence, itll do the same thing. any ideas?

hmm what error message do you get???

Anyway, I think it's in this line:

PHP Code:

---

    for(i=0;i<=eachword.size();i++){ 


---

I guess it should be

PHP Code:

---

    for(i=0;i<eachword.size();i++){ 


---

Because vectors are zero-based...
(ie. it tries to access an array item that's out of bounds)

now it just gives

hello
how
are

and it doesnt crash. maybe ill add in that last bogus entry

thanks :)

oh ok i got it. on the last time the loop runs, it doesnt get to add the last tmp in, i added that in after the loop and its fine.

thanks

hehe ok... most of the times it are the small things that can drive you nuts ;)

yep

one for question

you know how CString has its own functions...how do i access those though the vector?

Hmm to be honoust I never used the CString before, I always use a normal string from the standard library (include <string>)

But i guess you can access them in a way like:

PHP Code:

---

eachword[i].MyCStrFunc 


---

I haven't got vc fired up but I'll do it tomorrow if you haven't got the answer by than ;)

thanks.

that doesn't work

This should work though:

PHP Code:

---

((CString)eachword[i]).MyCStrFunc 


---

If this is your first time windows you shouldn't use MFC, much less mix MFC and STL. Learn API and stay completly with STL to take care of strings and you'll be fine.

Your problem:
i<=eachword.size()
must be
i<eachword.size()
because size returns the number of elements and vector is zero-based so the # of elements is 1 higher than the max index.

I can't find the option in .NET to make a dialog app w/o MFC. It was there in VS6, but in .NET there is only Console/Windows/DLL/Shared something

The windows one is like a full screen app, like games and things

No, even in VS6 there is no option "dlg app w/o MFC". You simply create a normal Win32 GUI app and don't code a window but rather a dialog. (Create a dialog template, call DialogBox, write a DlgProc and you're done - actually the DlgProc may require some time :))

I remember there was an option to do it without MFC, in the project wizard or something

whats wrong with mfc?

Quote:

---

Originally posted by nabeels786
whats wrong with mfc?

---

*cracks knuckles*

1: It doesn't teach you anything about Windows programming, you have to use the API to learn about the event model and message queues, etc.

2: It tries to implement its own container classes, with minimal use of templates - it should use the Standard C++ Library for these...that's what it's there for!

3: It's a very poor example of object-oriented programming, with far more virtual functions than are necessary, and too many raw pointers flying around.



I don't think anybody has designed/implemented a windowing system that actually follows the spirit of C++ and the Standard Library....if anyone has, PM me because I'd be interested to know :)

ok

got any good tutorials?

For what? API?

www.winprog.org :) Do a search for GetMessage on this forum (from me), since you need to use:

Code:

---

while(GetMessage(...) > 0)

---

...not...

Code:

---

while(GetMessage(...))

---

...this is because GetMessage can also return -1 which would still be an error, but would throw your app into an infinite loop.

alright thanks


thats alot of code for one window :eek:

It's a lot to create the window, but once you've got it you just need to keep adding things to the window procedure :)

Parksie, in response to the post above...
1) Very true, but it doesn't matter anymore once you know the API.

2) MFC is older than the STL. It is even older than RTTI (that's why it has it's own mechanism for this too). It stems from a time when templates were only seldom supported and the standard for those changed on a daily basis. It now has fully templated container classes.
The advantage of the MFC container classes is that they fit perfectly into MFC's other mechanisms like serialization. They are custom-made for the framework while the STL is for general purposes.

3) MFC has a lot of virtual functions (about 200 in the core MFC, that is no COM and other rare feature support). But while they generate overhead, they are what gives MFC it's power. The fact that you can derive from most classes to adjust their behaviour by overriding virtual functions gives your apps the ability not only to use the features openly exposed by MFC but also dig into it and get the hidden features (see Prosise's book for some impressive examples).
The raw pointers are bad, I think they should have used a lot more references, but this is because they didn't want to wander too far from the WinAPI to make it easier for programmers. And you can't set a reference to NULL.
MFC is not highly object-oriented. So what? What I like about C++ is that you can use OOP when it suits your needs, but it doesn't always do that. Sometimes functions are easier and more effective than classes. MFC does a good job of encapsulating the API in classes which is not an easy task.


The bottom line: if you like MFC I see no reason not to use it. If you don't like it, don't use it. It is surely not everyone's thing. But I don't see anyone making a better library of this magnitude.

You can't set a reference to NULL for a good reason ;)

Anyway, MFC is Windows only, and is very targeted (wxWindows doesn't look too bad though).

You might have noticed that I don't like being tied into a single platform (I go between X and Win32 :))

Yeah right, there IS a good reason that references can't be NULL, but sometimes you want to pass a reference to an object - or you don't want to. What then? You can pass NULL if it's a pointer but you have a problem when you pass a reference.

The portability thing is a good point. Which platforms (and environments) does wxWindows support?

Quote:

---

Yeah right, there IS a good reason that references can't be NULL, but sometimes you want to pass a reference to an object - or you don't want to. What then? You can pass NULL if it's a pointer but you have a problem when you pass a reference.

---

If you want to do that then you'd pass a pointer anyway, or use the Null Object pattern.

Quote:

---

The portability thing is a good point. Which platforms (and environments) does wxWindows support?

---

Win32, MacOS, and Motif (commercial X windowing library).

I think you can substitute Lesstif (free version of Motif)...

What is the Null Object pattern? Do you mean that an object in a special state is considered to be the same as NULL (like the string "")?

Is wxWindows commercial or free? I'd sure like to take a look at the source...

Yeah, that's about it :)


Free I think...the source is available.