|
Christian Graus wrote: Why would you declare a derived class as a friend ?
OMG I'm tired. I meant I declared a friend class an instantiated it. 
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
*grin* OK. Just making sure we're on th same page.
Basically, with .NET, they always try to make the language easy. friend classes are probably too hard, when the idea of allowing fall through in switch statements is completely impossible. I wonder if C++/CLI allows const methods, because C# and VB do not.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: I wonder if C++/CLI allows const methods,
Sure, as long as you don't declare them with the const keyword 
Direct quote from my output window...
"'const' and 'volatile' qualifiers on member functions of managed types are not supported"
|
|
|
|
|
Christian Graus wrote: *grin* OK. Just making sure we're on th same page.
Actually, I don't know what page I'm on anymore. Originally I was asked to write this code in VBA under Excel so that "others could use it easily". When I protested about how it would be excruciatingly slow (it's computationally intensive) nobody listened. But I coded it in VBA as requested.
After I coded it and it was shown to be excruciatingly slow they suggested Matlab. Again, I protested (Matlab is interpreted to). Nonetheless I coded it in Matlab. Again, painfully slow - actually worse than in VBA.
Finally I got my way and was invited to code it in C++. In a demonstration of my original point, one calculation went from 90 minutes under VBA to 6 minutes in C++. I started writing it in VS6 until it was suggested we "upgrade" to Visual Studio 2005. I was happty about being able to write it in c++, but this managed code stuff, well, I just don't know about this. Anyways, it's been a learning experience up to now.
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
Well, you don't have to use managed code, you shouldn't unless you specifically need it.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
This actually belongs in the C++/CLI forum ( you threw me, I actually told a few people they were in the C++/CLI forum  )
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: This actually belongs in the C++/CLI forum ( you threw me, I actually told a few people they were in the C++/CLI forum
Shows how much I know about CLI! 
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
In addition to Christian's excellent reply...
You also can't use multiple inheritance.
There's ways around all of it though, for the most part.
Access to protected members can be done through properties. From an OOP purist (I am not) point
of view, friend classes are probably a kludge anyway
You can't derive from multiple classes but you can derive from multiple interfaces.
Anyway, just because it's there doesn't mean you have to use it. If you're not using the .NET
framework then certainly don't use managed classes or even compile to CLR.
I personally use C++ for almost everything and managed C++ only for access to features of the
.NET framework, controlling compilation with #pragma managed/#pragma unmanaged.
Mark
|
|
|
|
|
Mark Salsbery wrote: friend classes are probably a kludge anyway
A little. But, making a property public throws away encapsulation entirely.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: A little. But, making a property public throws away encapsulation entirely.
How does that differ from using friend?
(I'm not arguing Like I said I'm no purist and I have some friend classes in my code. Just
enquiring for my own knowledge)
Mark
|
|
|
|
|
Mark Salsbery wrote: How does that differ from using friend?
I can decide who my friends are, and with whom I share things that are private. If I make those things public, then anyone has access to them.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Gotcha, thanks 
|
|
|
|
|
I guess with friend there's more control with granting specific access, where with a property
there's none.
Mark
|
|
|
|
|
Yes, exactly.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
The Apocalyptic Teacup wrote: If not, then what is the advantage of a managed class in C++?
C++/CLI is not really C++; it is a new programming language that targets .NET platform and aims to be backward compatible with C++.
|
|
|
|
|
Managed C++ (or C++/CLI as it's called in VC2005) isn't something you just tack onto an existing project. You should redo the code as managed only if you intend to make use of the BCL or want your code to be usable by other managed apps.
|
|
|
|
|
hi
is it posible that i can use an diectshow graph inside an dll ?
so i want to call this dll ofer an com interface .
the output of the filter is only a file.
with kind regards enrico hofmann
|
|
|
|
|
gigo2k6 wrote: is it posible that i can use an diectshow graph inside an dll ?
Why not?
gigo2k6 wrote: o i want to call this dll ofer an com interface .
If you want to create a COM object in-process (a COM DLL), then why not?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
ahh ok / is there a good manual for creating a dll for com on c++ ?
i also prefer german language if available, but english is also ok...
with kind regards enrico hofmann
|
|
|
|
|
gigo2k6 wrote: ahh ok / is there a good manual for creating a dll for com on c++ ?
Of course there are a lot (but I don't know them...)
When building a COM DLL, basically you have three ways:
(1) Using MFC COM support. This maybe the 'easyest way' (AFAIK Jeff Prosise's "Programming Windows With MFC" contains an introduction about, maybe enough...)
(2) Using ATL. This is a bit lower level, but it is also lighter and gives you (at least in my opinion) more power. About the argument I remember only Shepherd G., King B., "Inside ATL" a quite advanced book (Anyway using the ATL COM Wizard of Visual Studio it's strighforward).
(3) Handcrafting your COM component: there is a beatyful article series, written by Jeff Glatt, here at CodeProject, starting with [^].
hope that helps
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
If I programmatically create a CListCtrl in report mode (or derived class) without the WS_VISIBLE attribute, it blows chunks trying to init a header for it.
It blows when, during my header init, I try to delete any old header columns that might be there already. The header init is in a separate DLL, if that matters. Here's the line of code that blows:
int nColumnCount = pList->GetHeaderCtrl()->GetItemCount();
Any clues as to why this happens, or a workaround?
Thanx.
|
|
|
|
|
Exactly how does it blow chunks? Assertion error? BSOD?
|
|
|
|
|
First chance exception: Access violation trying to get the header.
Everything looks fairly normal, window handles ok, etc.
The only thing different between working and not, is the visible flag is removed when creating the control.
I'm presuming that the header control is not actually created until the list control is made visible. I can create the list control visible, and then hide it, but that's kind of hokey I think...
|
|
|
|
|
When you remove WS_VISIBLE you have this problem?and do you need to remove this style
|
|
|
|
|
I don't tthink it's a visibility problem.
Are you creating the control with the LVS_REPORT style?
Something is failing across this call "pList->GetHeaderCtrl()->GetItemCount();".
You can break it down...
1) If the listview control is created then pList should be non-zero and should have a valid HWND.
2) HWND hwndHeader ListView_GetHeader(*pList); should give you a valid HWND in hwndHeader.
3) int nItemCount = Header_GetItemCount(hwndHeader); should give a valid count.
If you're initializing a new control how can there be any columns in it?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
