Hmm. Problem with the "Lite" versions is they often hamstring you with limitations, like *not* giving you MFC at all, or letting you run "test" applications in debug mode, but not compile them to anything that is stand alone. I personally hate the latest batch of "learning edition" ones they put out do to that. Second is, since they don't include the GUI or any of the links needed to use Visual Studio if you already own it, your stuck with a learning curve that looks more like the side of Mount Everest than a comparatively simple cliff face. lol
Did download the one from Borland for kicks, but then never did anything with it. And, most of the latest "MS" version, after 6.0, are tied into the damn .NET stuff, which kind of defeats the purpose of finding a solution for a client that is meant to run on the widest variety of systems possible, including ones that **can't** run a version of .NET.
Now, as to my understanding. I have read the ATL book, a bunch of stuff on OLE, though I admit not what I was looking for, dug through various thread on places about the subject of events, etc. I probably know more than anyone here about how it fits together, despite having missing pieces. Those pieces look, at the moment, more like the 1-2 that inevitably get stuck on someone's shirt or land upside down on the floor of the kitchen, not the gapping hole that you get when you have all the edges, but nothing else has been placed yet. My personal opinion is that, while its probably not going to be a mere one or two lines, its also not going to be like 200 either.
Most of the issues I see arise not do to the complexity of the solution, but the complexity of the hoops some clown put in the way of getting it to work. For example, implimenting a call to the invoke method of an ActiveX control, to tell it to connect an event to a sink "should be" one line. In any language that directly supports the implimentation is it. In raw C++, with no libraries helping you out, you have to do like a dozen other things, from making calls to the system metrics to get ...something... before the OS will "let" you call it. Why? Because you *might* make a call to invoke that is effected by those things, even if what you are trying to call has jack to do with any of them. I gave up on that approach after trying to trace the mess for doing it through the .h and other files in my ancient version of C++ that I do have. Haven't been so annoyed by the convoluted gibberish in someone else's library implimentation since I tried to figure out how the heck command parsing worked on an Apple IIgs, where the code was about 10 machine instructions that are identical to the older Apple I, II, II+, IIe and IIc, except where it made a long jump to some upper memory location where the new IIgs bios was, and proceeding to mangle things beyond all recognition. Near as I could tell, and I know I missed something, the "code" in that location always returned an invalid value, which should have stopped the parser from working at all...
The coders where either way smarter than me, completely insane, or both. lol I felt the same way trying to figure out how invoke calls worked according the the library descriptions for what ever it was I was looking at in the C++ mess. And, since then, I read stuff that implies that about 90% of it is completely unnecessary if all you are doing is telling the object to link an event. Its all there "in case" you need to do one of like 50 other things.
This is one reason why I am sure its simpler than it looks. Yeah, there are bound to be a dozen "complicated" solutions, but in nearly every case those are complicated because they are doing *more* than what I am trying to solve in the first place. Its like trying to fix a tire and having someone insist you read the *entire* repair manual starting with page one, before they let you see page 50, which tells you how to change the tires (which happens to be an after thought in the section about replacing the entire transmission).
Its about finding the "best" solution, not just any solution, and there are lots of *bad* ones that are way more complicated than strictly necessary. Most are "bad" in this case because they assume you are starting from pure scratch and you can't even create the object, much less look at its attributes or call its exposed functions, and calling its "hidden" functions is part of getting to that point, with, much like changing the tires, the use of events being either ignored entirely, or tacked on as an after thought. And that is with ActiveX, which is presumably a well known system. For standard system events.... I haven't yet even tracked down anything that says conclusively *if* ActiveX and standard events even relate to each other, since the former is designed to circumvent a lot of the limitations of the prior structures, due the them being "too" rigid in the first place. Its not just possible, but maybe even likely, that the solution for ActiveX is *nothing* like the solution needed for something like the wx libraries. What I have learned seems to imply this as a real possibility.
Anyway.. Got to dig out some cash and buy the OLE book I guess. There is also a so called "standard edition" of Visual Studio, which if I get the C++ version is cheaper (asseming 6.0 had such a version). Or.. Maybe I can find some relative in college who can get it through a school discount. My previous source... Lets just say, without disparaging any beliefs she thinks she holds, that I have more ethics than she does and thus won't intentionally use even the most selfish fool to serve *my own* selfish desires, unlike someone else I might name... |