C / C++ / MFC

Maximilien5-Dec-02 5:24

5-Dec-02 5:24

a struct in C++ is a class with all member public by default.

a class in C++ is a struct with all member private( or protected, don't remember ) by default.

Smile | :)

so, struct and class can be interchangeable! In your example, they are the same.

Max.

User 98855-Dec-02 5:29

User 9885

5-Dec-02 5:29

Why is it that interfaces are always structs then?
Is there any performance advantage OR is it that people are lazy to write public: ?

I got intrigued by this because I always used class for creating interfaces and then I see the line #define interface struct in MSDN. I wondered why?

My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers

modified 29-Aug-18 21:01pm.

Maximilien5-Dec-02 5:45

5-Dec-02 5:45

Thomas George wrote:
Why is it that interfaces are always structs then?

maybe because everything should be public by default.

Thomas George wrote:
Is there any performance advantage OR is it that people are lazy to write public: ?

I think the struct/class (the same for public/private/protected ) , is a compilation hint, it does not change the object ( in memory ), or the "performance" of an object.

Max.

Daniel Turini5-Dec-02 6:08

Daniel Turini

5-Dec-02 6:08

Thomas George wrote:
Why is it that interfaces are always structs then?
Is there any performance advantage OR is it that people are lazy to write public: ?

I got intrigued by this because I always used class for creating interfaces and then I see the line #define interface struct in MSDN. I wondered why?
It is done so they can be used in regular C code, too.

I see dumb people

How to Expose two COM interfaces

User 98855-Dec-02 6:11

User 9885

5-Dec-02 6:11

That clears it up rather nicely, Big Grin | :-D

Thank you

My article on a reference-counted smart pointer that supports polymorphic objects and raw pointers

modified 29-Aug-18 21:01pm.

Alois Kraus5-Dec-02 5:08

Alois Kraus

5-Dec-02 5:08

Hello,

I have an ActiveX Control which is embedded in another application which works fine.
The only problem is that
some peers want to test the control in the application before we ship the
product. From my point of view:
Automated Tests = COM, so I came up with the idea to make a second COM interface
and register it in the ROT (Running Obect table). This Interface gives
full access to my ActiveX control.
I have not done this before so I would like get some opinions how
this could be done in the best object oriented way.

Can I use the same .ODL file for my ActiveX project and insert
there the second interface ? What must I do to implement a second COM interface
by myself ?

Yours,

Alois Kraus

Re: How to Expose two COM interfaces

peterchen5-Dec-02 7:37

peterchen

5-Dec-02 7:37

There are two basic ways to expose a secondary interface:

a) local classes (MFC does that, including some dirty tricks to make this effective)
b) multile inheritance (ATL does that)

b) is IMO much cleaner, only you can get into problems with method name clashes
Some pseudocode for the latter:

class CCoImpl : public IFun, public ITest
{
   HRESULT QueryInterface()
   {
      if (iid == IUnknown) {  // always return the same pointer when specifically asked for IUnk; which one doesn't matter
        addref, return static_cast<IFun *>(this);
      }
      if (iid == IFun) {
        addref, return static_cast<IFun *>(this); 
      }
      if (iid == ITest) {
        addref, return static_cast<ITest *>(this);
      }
     return E_NOINTERFACE;
   }
   // IFun methods:
   HRESULT GoShopping() { ... }
   HRESULT GoRocking()  { ... }

   // ITest Methods
   HRESULT TestCountShoes(....) { ... }
};

you get the idea...

Neither way you can expose two dispatch (or dual) interfaces - you can only have obe dispatch-based interface per object.

If I could find a souvenir / just to prove the world was here [sighist]

Visible area of CDC

S O S5-Dec-02 4:07

S O S

5-Dec-02 4:07

How can I get the visible area of a window's CDC(In the paint function)?
I am trying to draw a grid, but drawing it on the whole thing would be wasteful(It's big!)

Re: Visible area of CDC

Maximilien5-Dec-02 4:18

Adding a printer driver programmatically

5-Dec-02 4:18

Huh ?

You normally draw in the client area of a window ( GetClientRect ), should be clipped, for additional clipping, look for them in the CDC help of MSDN.

Max.

Re: Visible area of CDC

Paul M Watt5-Dec-02 5:31

Paul M Watt

5-Dec-02 5:31

Use the function ::GetRandomRgn with the SYSRGN flag. You may need to download the most current SDK headers in order to use this function.

I have written this article on clipping regions:

http://www.codeproject.com/gdi/cliprgnguide.asp[^]

It describes the system region, clipping region and meta region. It also has an example of how to get the imformation that you are asking for.

Good Luck

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!

Re: Visible area of CDC

S O S5-Dec-02 10:04

S O S

5-Dec-02 10:04

Thanks!

Adrian von Gunten5-Dec-02 3:53

Adrian von Gunten

5-Dec-02 3:53

I'm trying to add the "Generic / Text Only" printer driver programmatically.

I've used AddPrinterDriver and AdPrinterDriverEx from the API but the driver doesn't work.

Did anybody solve this problem or have anybody some suggestions?

checking a pipe status

Martin Blanc5-Dec-02 3:43

Martin Blanc

5-Dec-02 3:43

I've got a named pipe. One process writes to its (let's call it A) side, and the other process reads from its oposite (B) side. The process at the B side can randomly connect to and disconnect from the pipe. I'd like to prevent the A-side process from even trying to write to the pipe if the B-side process is disconnected. How can A-side process check the B-side pipe status? I have an idea of using PeekNamedPipe() with all its pointer parameters set to NULL and, when I get return value zero, interpret the result of GetLastError(), but this idea by no means seems that smart to me.
Any suggestions? Is GetNamedPipeHandleState() of any use in these situations?

TIA
Martin

Re: checking a pipe status

Alois Kraus5-Dec-02 23:29

Alois Kraus

5-Dec-02 23:29

I did use PeekNamedPipe for this purpose and it worked perfectly.
I use a one byte reciever buffer in the PeekNamedPipe function.
You could of course use WriteFileEx with an completion Routine and wait
for an error to occur.

A live ping always involves sending packets and check if the reciever responds
to it. There is simply no other way to check if somebody has unplugged Your network cable. PeekNamedPipe does exactly this in a transparent way without disturbing
your data transfer.

Re: checking a pipe status

Martin Blanc6-Dec-02 4:54

Martin Blanc

6-Dec-02 4:54

Thanks for your reply. Now I know I'm standing on the firm ground. Sometimes it's better to learn from others' successes instead of my own failures. Smile | :)

Martin

VC.NET vs VB.NET

devvvy5-Dec-02 3:20

5-Dec-02 3:20

hi, pretty new to .NET. But just want to make sure that i pick the right tool for a development project.

Project: coporate infrastructure - from scratch. Areas of concern involves: SQL Server 2000 dev/DMO, Active Directory, IIS (web server and FTP), security (Crypto), Exchange Server, Web application/service, WIN 2000 Adv Server.

Why Choose VC?
1. Backward compatibility
2. speed

but since:
1. this is a infrastructure project starting from scratch, we're not really concerned with "backward compatibility"? I presume there'd be no problem integrating COM components into VB.NET code.

2. speed. VB.NET is not any slower than VC.NET.

3. GUI. VB has a much better dialog editor than VC.

Just want to re-confirm my understanding. My preferred development tool for project like this will be VB.NET.

What do u think?

norm

Maximilien5-Dec-02 3:39

5-Dec-02 3:39

I have absolutly no experience with VB or any of the technologies you are talking about! so take this with a brick of salt!

There's nothing wrong with either of them.

Use the language that you feel more confortable with! ( this is the most important point ! )

You can always create external DLL in C++ for more computational intensive stuff, or things that are easier made in C++ than in VB.

Some people will suggest using C#.

Max.

devvvy5-Dec-02 3:49

5-Dec-02 3:49

QUOTE: "You can always create external DLL in C++ for more computational intensive stuff,"

sure. but isnt it true that all .NET languages compiled to IL? speed is more or less the same among all .NET languages?

QUOTE 2: "or things that are easier made in C++ than in VB."

any examples?

norm

Daniel Turini5-Dec-02 5:02

Daniel Turini

5-Dec-02 5:02

norm wrote:
sure. but isnt it true that all .NET languages compiled to IL? speed is more or less the same among all .NET languages?
Yes and no: under C++ you can mix unmanaged and managed code, so you can still generate native code with a ".NET face"

I see dumb people

Rickard Andersson²⁰5-Dec-02 3:58

Rickard Andersson²⁰

5-Dec-02 3:58

Abolish VB!

I will not say anything more... I've said too much about what I think of VB in these forums... Suspicious | :suss:

Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!

Michael P Butler5-Dec-02 4:03

Michael P Butler

5-Dec-02 4:03

If you want to write managed .NET code, go with C# and use managed C++ for wrapping legacy code.

Don't even think about VB.NET; It is a poor language, has no advantage over C#. There are a lot of bodges in VB.NET to keep old VB programmers happy.

Everything you can do in VB.NET, you can do in C# and C# will give you a more solid code base.

Michael

Fat bottomed girls
You make the rockin' world go round -- Queen

devvvy5-Dec-02 4:10

5-Dec-02 4:10

that's something new. i did play with VB.NET a little, seems very nice and efficient. where can i read up a lil more on how exactly is c# better than VB.NET?

thanks!

norm

Daniel Turini5-Dec-02 4:29

Daniel Turini

5-Dec-02 4:29

norm wrote:
where can i read up a lil more on how exactly is c# better than VB.NET?
I use both a lot, and I can say there are some strong points favorable to C# over VB.NET:

.C# has a much cleaner syntax. No legacy compatibility to concern about.
.It may seem stupid, but VB IDE has an auto-identing "feature" extremely annoying
.C# has the "using" statement for automatic destruction of IDisposable object instances. VB.NET code will need to use lots of Try/Catch code to do the same thing and is very probable having resource and memory leaks under it.
.C# can go "unsafe" and use pointer manipulation.
.C# can create more than one namespace per project.
.C# can control on code block basis, wether the integer arith. expressions are checked or not.
.C# can stack allocate arrays which will not be garbage collected
.By default, C# is type-safe (Option Strict On), and a clean syntax for type coercion. This is a thing VB programmers will have a hard time catching on.
.VB.NET has a very weird syntax for calling static class members
.VB.NET has two error handling models: some functions will raise errors, other exceptions. This leads to interesting bugs.
.Under C# you can have static class constructors. This can eliminate several "if x is Nothing" statements and reduce coding.
.Signed ("Strong Named") assemblies in C# can generate signed Interop assemblies right from the IDE when calling legacy COM code. Under VB.NET you'll have to resort to tlbimp.

I'm specially concerned about the C# audience and the VB.NET audience. The next version of C# has been already anounced with tons of nice and useful features, like templates, anonymous delegates and iterators. Nothing of these will be available to VB.NET soon, because it's too complicated for VB.NET programmers.

I see dumb people

devvvy5-Dec-02 4:38