C / C++ / MFC

MFC without a dialog or view?

9-Dec-00 9:46

It's in m_object.word. You can access all the variables this way, but remember you can't get data from variables attached to edit boxes & the like, because they don't exist anymore.

Christian

The content of this post is not necessarily the opinion of my yadda yadda yadda.

To understand recursion, we must first understand recursion.

Re: Dialog

Matt Philmon9-Dec-00 9:54

Matt Philmon

9-Dec-00 9:54

Sure. Either make the members public or create access functions.

CMyDialog dlg;
CString strWord;

if (dlg.DoModal() == IDOK)
{
strWord = dlg.word;
}

8-Dec-00 14:08

How do I create an MFC application without a dialog or a view? When I put my code in InitInstance it exits and I don't want to use an infinate loop due to cpu. What is the correct way to do this?

Erik Funkenbusch8-Dec-00 18:03

8-Dec-00 18:03

I'm not sure I follow you. Why do you want ot use MFC if you're not going to open windows? If you just want to use the MFC utility classes (CString, CList, etc..) you can do so without creating a CWinApp derived class.

8-Dec-00 19:23

Yeah MFC or no MFC.. but how would I keep my program running in the background without an infinate loop?

Erik Funkenbusch8-Dec-00 21:58

8-Dec-00 21:58

That depends on if your program accepts messages or not. If it does, then you wait in a loop on GetMessage(), if not then you can use Sleep to give up processor time to other programs or run your program at a low priority.

10-Dec-00 21:46

This doesn't seem to work. It loops then hangs while waiting for the message.

Erik Funkenbusch11-Dec-00 12:17

Minimized Window doesnot show up

11-Dec-00 12:17

Alright, it seems clear that you really don't understand what you want, or cannot communicate it well enough for anyone to understand.

You said you wanted to loop without using CPU time, I told you how, now you're complaining that it's not looping????

Either you want it to loop all the time, or you want to wait for something to trigger a loop, which is it?

8-Dec-00 9:38

A normal window (CFrameWnd) does not pop up after it was
minimized when clicked on its icon. But it is poped up
if right clicked on the minimized icon and selected
'Restored' or 'maximized' menu.
What would have gone wrong?

Help with string class - return char *

Christian Graus7-Dec-00 12:04

7-Dec-00 12:04

Hi all. I'm trying to write a string class ( we want to move away from MFC as we want to develop a cross platform product ), and I am starting by deriving from the standard string class. My header looks like this:

#include <string>

using namespace std;

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

class CGString : public virtual string
{
public:
CGString();
virtual ~CGString();

};

My problem is, I want to do this:

CGString s;
s = "dfdsfs";
printf(s);

And it's telling me = is not defined for this input type, and that it cannot convert from CGString to char*. I'm not sure *why* I need to provide the operator= again, but that's cool. I want to know how I can make my variable return a char*, in essence to cast itself to it's data member ? I know I can use .GetBuffer() or whatever, but I don't want to, if I can avoid it.

Thanks for helping...

Christian

The content of this post is not necessarily the opinion of my yadda yadda yadda.

To understand recursion, we must first understand recursion.

Michael Dunn7-Dec-00 13:35

Michael Dunn

7-Dec-00 13:35

A derived class does not inherit operator = from its base class. That's Just The Way It Is^tm.

As for your second part, I think you are asking about writing a conversion operator for the class, right? You could do something like this:

CGString::operator const char* ()
{
  return c_str();
}

--Mike--
http://home.inreach.com/mdunn/
"Didn't I tell you? I've got a brain the size of a planet."
--Marvin the paranoid android

Christian Graus7-Dec-00 14:04

7-Dec-00 14:04

Wow - cool. Thanks, that's my thing learned for the day....

Christian

The content of this post is not necessarily the opinion of my yadda yadda yadda.

To understand recursion, we must first understand recursion.

Erik Funkenbusch8-Dec-00 10:20

8-Dec-00 10:20

Actually, think long and hard about deriving from the standard classes in most cases.

std::string doesn't have a virtual destructor, thus if someone does this:

std::string *p = new CGString;
delete p;

You're off into weird and undefined territory. Declaring your destructor virtual won't help.

What's wrong with std::string that you need to change it? And why not just write some utility functions that accept a std::string to do what changes you need?

Christian Graus8-Dec-00 12:22

8-Dec-00 12:22

Oh. I didn't realise that, I assumed that the destructor would be virtual to allow for people to expand on the standard class. An assumption I make after mainly extending MFC classes, I guess.

The idea is that we have a product now which we want to port to Mac & Linux, and so we want to replace MFC classes like CString with something that will work in any C++ environment. Specifically I want to be able to replace any instance of CString in our existing code with CGString and have it work which means adding functions that simply call existing functions that have different names to the same functionality in CString, and adding those that are missing, like MakeLower ( which we use ALL the time for name comparison on files ) and Format. I personally don't like the idea of external functions, because I want a string to remain an object that knows how to do what I want it to, not something that is subject to external code for what I consider basic functionality.

I suppose that means I need to write the whole thing from scratch then ?

Christian

The content of this post is not necessarily the opinion of my yadda yadda yadda.

To understand recursion, we must first understand recursion.

Erik Funkenbusch8-Dec-00 18:25

8-Dec-00 18:25

I take it you mean you want to create a class with the same interface as CString, which is portable.

You can mostly achieve this by using a std::string as a member of CGString class, then set up forwarding functions that call members in string, or alternatively you can use private inheritance of std::string. This will make it so that you can't assign a CGString pointer to a a std::string pointer.

However, it won't be possible to completely duplicate CStrings functionality for a variety of reasons, especially if you provide a virtual destructor.

If you look at CString, you'll also see that it doesn't provide a virtual destructor. The reason is simple:

You can cast a CString to a char* and use it as if it were an array of characters. It does this by making the array pointer the first member in the class, thus a pointer to the CString is also a pointer to it's first member. In classes that have vtables though, the pointer to the class is also the pointer to the vtable, which would not work.

This isn't exactly good behavior though, so you might just want to say "You can't do that in my CGString", which would be fine unless you have existing code which expects that.

As far as external functions go, I think you're stuck in "everything has to be an object" mentality. Look at the standard C++ library. It provides all kinds of functions called algorithms that work on generic objects. These algorithms aren't part of the objects themselves, and it's still object oriented. You don't have to make everything a member for it to be OO. This is the biggest mistake most people make when using C++, too much encapsulation.

The things you mention are easily accomplished with external functions and std::string. You want to make lower, just use:

std::string s("ThIs Is A mIxEd CaSe StRiNg");
std::transform(s.begin(), s.end(), s.begin(), std::tolower);

Format is indeed handy, but it's simple enough to create your own format function that does the same thing using sprintf.

Christian Graus9-Dec-00 9:42

9-Dec-00 9:42

>I take it you mean you want to create a class with the same interface as CString, which is portable.

Yes.

>You can mostly achieve this by using a std::string as a member of CGString class, then set up forwarding functions that call members in string,

Yes, that is what I do where possible - no point reinventing the wheel, and that was the point of inheriting string.

>or alternatively you can use private inheritance of std::string. This will make it so that you can't assign a
CGString pointer to a a std::string pointer.

Hmm... If I provide interfaces to *all* of string, then I *could* do that.... Any down side ?

>However, it won't be possible to completely duplicate CStrings functionality for a variety of reasons, especially if you provide a virtual destructor.

Actually, given that string's destructor will always be called, I removed my destructor, forgetting that I will be given one anyhow by my compiler. Some thought needed there, methinks.

>If you look at CString, you'll also see that it doesn't provide a virtual destructor. The reason is simple:

>You can cast a CString to a char* and use it as if it were an array of characters. It does this by making the array pointer the first member in the class, thus a pointer to the CString is also a pointer to it's first member. In classes that have vtables though, the pointer to the class is also the pointer to the vtable, which would not work.

So I can't cast to char* in my class for this reason then ?

>This isn't exactly good behavior though, so you might just want to say "You can't do that in my CGString", which would be fine unless you have existing code which expects that.

I doubt we have code that expects it, but this could be hairy, none of us there now were there for the early to mid stage of thge project.

>As far as external functions go, I think you're stuck in "everything has to be an object" mentality. Look at the standard C++ library. It provides all kinds of functions called algorithms that work on generic objects. These algorithms aren't part of the objects themselves, and it's still object oriented. You don't have to make everything a member for it to be OO. This is the biggest mistake most people make when using C++, too much encapsulation.

Fair enough. Although I understand what you're saying in general, surely you'd agree 'format' and 'makelower' are not terribly generic ?

>The things you mention are easily accomplished with external functions and std::string. You want to make lower, just use:

>std::string s("ThIs Is A mIxEd CaSe StRiNg");
>std::transform(s.begin(), s.end(), s.begin(), std::tolower);

I s'pose, but s.MakeLower sees to me easier to read and easier to use.

>Format is indeed handy, but it's simple enough to create your own format function that does the same thing using sprintf.

Funny you mention that, because I've done this:

CGString& CGString::Format(const char* pChar, ...)
{
if (strlen(pChar)<2)
return *this;

va_list argList;
va_start(argList, pChar);
char* pReturn = new char [400];
memset(pReturn,0,400);
sprintf(pReturn,pChar,argList);
va_end(argList);
this->assign(pReturn);
return *this;
}

as a starting point ( I wanted to get it to work *at all* before cleaning it up, for starters I need to allocate a correct size to the char * that receives the data instead of an arbitrary value ) and it compiles, runs and returns garbage in the sections of a string that is formated, but correct data for the section that was in the format string. For example:

int i = 27;
CGString g;
g.Format("test me %d",i);

would leave g equalling "test me *insert big number here". Can you see what I've done wrong ?

Thanks for all the help & advice. I admit to being far more up on MFC than standard C++ right now, which is half the reason I put my hand up for this class, to study a bit and redress the balance.

Christian

The content of this post is not necessarily the opinion of my yadda yadda yadda.

To understand recursion, we must first understand recursion.

Erik Funkenbusch9-Dec-00 12:54

9-Dec-00 12:54

Before embarking upon your journey, Grasshopper, one should always see if someone else has gone there first.

Joe O'leary has made a CString replaceable class at:
http://home.earthlink.net/~jmoleary/projects.htm

Also, I think there may be literally hundreds of them out there.

In your code, you need to pass argList by value, instead of by pointer. va_list is a typedef for a pointer to argument, you need to pass the actual arguments.

sprintf(pReturn,pChar,*argList);

Christian Graus9-Dec-00 21:28