Just a liitle question abou VC++ and MFC

[SignOff]

HI,

I'm using a MSVC++ 7.0 with MFC.

Let'ssay I created a class derived from CStatic:

class Card : CStatic
{
......
}

Now, i want to use one in my CView loading a card.dll.

So what I'm doing:
CCView::OnDraw(CDC* pDC)
{
card = new CCard();
hModule = LoadLibrary("cards.dll");
card->Create("", WS_CHILD|WS_VISIBLE|SS_BITMAP|SS_CENTERIMAGE
,CRect(10, 10, 82, 107), this);
card->SetBitmap:LoadBitmap(hModule,MAKEINTRESOURCE(card->CardNumber)));
.....
}

but its now working. Will you set me by right way?
Idea is simple. We have a control CCard and want to engage in CView
with proper bitmap getting from cards.dll

Thanks in advance.

 

[Duane Hebert]

HI,

I'm using a MSVC++ 7.0 with MFC.

Let'ssay I created a class derived from CStatic:

class Card : CStatic
{
.....
}

Now, i want to use one in my CView loading a card.dll.

So what I'm doing:
CCView::OnDraw(CDC* pDC)
{
card = new CCard();
hModule = LoadLibrary("cards.dll");
card->Create("", WS_CHILD|WS_VISIBLE|SS_BITMAP|SS_CENTERIMAGE
,CRect(10, 10, 82, 107), this);
card->SetBitmap:LoadBitmap(hModule,MAKEINTRESOURCE(card->CardNumber)));
....
}

but its now working. Will you set me by right way?
Idea is simple. We have a control CCard and want to engage in CView
with proper bitmap getting from cards.dll

What's the error? Are you trying to use something from the CStatic
when Card is derived privately? If so, try

class Card : public CStatic {

If you don't specify public here, it defaults to private. If this isn't
your problem,
you should indicate your error.

 

[Howard]

HI,

I'm using a MSVC++ 7.0 with MFC.

Let'ssay I created a class derived from CStatic:
[snip]

... Will you set me by right way?

Nope, but someone on an mfc newsgroup might. Try microsoft.public.vc.mfc
(you may want to use their server: msnews.microsoft.com).

-Howard

 

[Ron Natalie]

HI,

I'm using a MSVC++ 7.0 with MFC.

Let'ssay I created a class derived from CStatic:

Microsoft MFC is an abomination when it comes to C++
OO design. Most of the functions you think ought to
be virtual AREN'T, it uses the message maps to invoke
the derived class functions directly.

This is all off-topic here, read a good book on MFC

 

[Code4u]

Microsoft MFC is an abomination when it comes to C++
OO design. Most of the functions you think ought to
be virtual AREN'T, it uses the message maps to invoke
the derived class functions directly.

100% agreed that it is much better to spend years designing a
beautiful library with lots of templates, huge vtables that map every
message, infinite configurability, and standards conformance that
makes it look like pig and run like a hog on every platform.

 

[Ron Natalie]

100% agreed that it is much better to spend years designing a
beautiful library with lots of templates, huge vtables that map every
message, infinite configurability, and standards conformance that
makes it look like pig and run like a hog on every platform.

Are you trying to tell me that MFC is more efficient than if it
had a scant amount of OO design in it? I don't agree.

 

[Ron Natalie]

100% agreed that it is much better to spend years designing a
beautiful library with lots of templates, huge vtables that map every
message, infinite configurability, and standards conformance that
makes it look like pig and run like a hog on every platform.

Microsoft can do OO right and efficiently. Take a look at GDI+.
Unlike it's cousin the MFC wrappers for the GDI primitives, it
actually appears someone knew how to program in C++ prior to writing
it.

 

[Ioannis Vranos]

Microsoft can do OO right and efficiently. Take a look at GDI+.
Unlike it's cousin the MFC wrappers for the GDI primitives, it
actually appears someone knew how to program in C++ prior to writing
it.

As far as I know GDI+ is a subset of .NET. .NET is nicely OO with multiple inheritance to
be available only through interfaces though (which is sufficient for most cases of
application programming I think).

 

[Ron Natalie]

As far as I know GDI+ is a subset of .NET

GDI+ isn't really part of .NET, but .NET uses it.

Microsoft has evolved in the 15 years or so MFC has been
around. Much of their newer stuff is much better than
the the relics from the DOS days

 

[Code4u]

GDI+ isn't really part of .NET, but .NET uses it.

Microsoft has evolved in the 15 years or so MFC has been
around. Much of their newer stuff is much better than
the the relics from the DOS days

In all seriousness, I have a lot of experience with MFC, it's ugly in
places, but it gets the job done and scales up very well. As a
framework it is very flexible, if you don't like the way part of MFC
works you're free to derive your own classes and roll your own, or mix
and match with win32/ATL/WTL for example. Regarding message maps, this
implementation is very efficient, you don't pay for what you don't use
and there is very little run-time overhead. We're way off-topic here,
but I'll end by saying that although .NET has some good design, it's
still a buggy mess in places, this comes straight from the mouth of
Jeff Richter. For example, interop code cannot be debugged because
Visual Studio doesn't transition from managed to unmanaged code well.
Bottom line is MFC is solid, reliable, has source code available, is
extensible and has a huge knowledge base. Beautiful design is just one
factor to be considered and is often prioritized too highly by the
inexperienced.

 

[Ron Natalie]

Regarding message maps, this
implementation is very efficient, you don't pay for what you don't use
and there is very little run-time overhead.

Chortle. If you have anythign beyond a trivial application, the
stupid-assed MFC command mapping is FAR from efficient. I've got
so manu things in the message map for the main window in my applicaiton
that VC++ 6's class wizard gags and refuses to interpret it.

Ever trace through what happens during ON_COMMAND processing? It's
laughable.

 

[Ioannis Vranos]

GDI+ isn't really part of .NET, but .NET uses it.

Do you mean that .NET provides a managed wrapper of it, while it is available in native form?

 

[Ron Natalie]

Do you mean that .NET provides a managed wrapper of it, while it is
available in native form?

I believe that is the case...you can install the GDI+ dll's without
the .NET framework.

 

[Ioannis Vranos]

I believe that is the case...you can install the GDI+ dll's without
the .NET framework.

OK.

 

[Ioannis Vranos]

I believe that is the case...you can install the GDI+ dll's without
the .NET framework.

I asked in an MS newsgroup and GDI+ is a native API indeed:

Is GDI+ a subset of .NET

No. GDI+ is a native API.

See: GDI+
http://msdn.microsoft.com/library/en-us/gdicpp/GDIPlus/GDIPlus.asp

or does .NET just provide a managed wrapper of it?

Yes.

See: About GDI+ Managed Code
http://msdn.microsoft.com/library/en-us/cpguide/html/_gdiplus_About_GDI_Managed_Code_about.asp