Using MFC

[BryanW]

I'm just beginning to use this desktop API, and I'm trying to get it to work with MFC (Microsoft Foundation Classes). I'm also new to all the COM, ActiveX, and automation stuff. So I'm having trouble just getting the ESignal object created and connected successfully.

I've attached a file called DataServer.cpp. This file has a member function called Run, which will eventually download historical data, but I can't seem to get past the initialization phase. I always get the TRACE message "... OLE Exception caught: SCODE = 800401F0". And the SCODE refers to CO_E_NOTINITIALIZED.

for your information I have added the following lines to stdafx.h

// Import the type library file for the eSignal Desktop API
#import "C:\Program Files\eSignal\winsig.tlb" no_namespace

And the class CHooks was automatically generated for me from "winsig.tlb"

If anyone has any experience with MFC and automation, I would appreciate any tips. I suspect that what ever I'm doing wrong must be fairly simple to fix. I simply lack the experience to know what it is.

Thanks,
Bryan

[allank]

Microsoft supports MFC for existing projects. They recommend new projects be written for .NET framework.

[JimBecker17]

Your app needs to call ::CoInitialize(NULL) in InitInstance() method.

In ExitInstance() you then call ::CoUninitialize() routine.

These setup the app to use OLE/COM world.


I would refrain from going down the .NET path if you are not doing true Internet programming, but that is personal opinion. I'm still using C++/MFC although have worked with .NET and C#.

-Jim

[BryanW]

Thanks for your help. the CoInitialize call was the key. I also prefer C++/MFC. Though I must admit that using ESignal in C# is much easier. Well at least the initialization part is easier. Everything else about C# is a pain. Ok, maybe its not that bad. But I do miss the complete control which the .Net framework has stolen from me.

Thanks again,
Bryan

[GenSpoo]

What control has .Net stolen?

I personally like C# and use it for almost any new project I start. I still do a lot of C++/MFC, but mainly for maintaining and adding to existing projects.

Cheers... George

[JimBecker17]

Hi Guys,

I didn't mean to start a religious war, too many battle scars from Unix days.... and too many fresh wounds from 0x014 battles...

My exposure to .NET and C# proved it to be a good venue for smaller object based creations designed for class factories and internet type needs. (Of course it seemed ungodly slow even on dual Xeon machines...)

These projects do lead you down a certain path, just as the doc/view architecture leads you on a path in MFC. But the path seems more confined.

With C++/MFC one can have more flexibility and build much larger and exotic apps, in my opinion.

Most of my apps are pretty big though, multi-year efforts.

-Jim

[BryanW]

Since the question was asked, I'm going to used this thread to vent regarding "what has .NET stolen". I hope no one takes this too personally.

There are no pointers only references. I can't get the address of anything. So I can't manipulate memory at the low level.

It is confusing at first to know the difference between a value and a reference. The syntax in C# is identacle. In C++ the syntax is explicit. You can now very clearly when you using a value or using it as a pointer.

I can't use sizeof with out declaring my code unsafe.

const in C# is like #define in C++. Therefor I can't create an object and then cast it to a const for read only reference by another object.

Garbage collection is a pain. With C# I have to explicitly call a Dispose method to make sure something is cleaned up on time. In C++ the destructor is called implicitly when ever an object goes out of scope.

Now these features of .NET probably do prevent a lot of bugs. But only because it takes away a lot of control from those programmers whom Microsoft believes would, otherwise, create a lot of bugs.

Bryan

[GenSpoo]

I'm not a fan of the religious wars either. So all I'll say further is I don't think any of those things are of much consequence to most programmers in most applications.

Who really needs pointers except kernel and hardware programmers? Don't get me wrong, I love C/C++, have written assembler, blah, blah, blah, but I still think C# has lots of benefits. And no more GPFs and memory leaks is a good one. The .Net libraries have a lot of good classes to work with, which you are free to ignore if you like your own better.

In the end it should only come down to using the right tool for the job. Sometimes that is C++, sometimes that is C#, some times (ok, rarely) it is assembler. For me, and I've been using C++ for many years, I like working with C# better and although I've had to give up some of my old techniques, I have found equivalent methods that I like just fine. I bet in 10-20 years, we'll have the same discussion about C-flat and what it stole from with respect to C#.

Cheers... George

[DionLoy]

The new C++/CLI syntax, replacing Managed C++ Extensions looks great though.

Best of both worlds ... the extensive .NET Framework, and the ability to use C++ with a MUCH nicer syntax than MC++.NET, determinalistic destructors, ability to drop down to native C++, pointers, etc.. .NET objects within STL containers too.

[BryanW]

I'm a driver writer by day. So I like pointers. But I must agree there are many conveniences for using .NET in the application world.

with that said, let peace return.

Bryan