Hi,

Heres a full OCX/Active-X control without any usage of Ernies CoLib or other restricted software. Event sinks are supported, of course. For all those people having trouble with this CoLib thing.


japheth
Posted on 2002-01-10 03:59:16 by japheth
it works except for the fact that it crashes my internet explorer/windows explorer when I decide to exit the page :-/
Posted on 2002-01-10 11:12:10 by Hiroshimator
Do be careful when using j's code.

WARNING: The control in the source file CAN NOT be unregistered without manually editing the registry. You may be stuck with this thing forever on your system.

Any other things it may do are unknown, as this is a large project without documentation.

Please note the people who manage this menagerie DO NOT preview and approve code posting.

So you run this code at your own risk.
Posted on 2002-01-11 00:30:21 by Ernie
Dear Hiro, dear Ernie,

you both are right.

- crashes with IE: This sample was tested with VB, Test Container of VC and IE. It crashes when exiting IE. Hope I can find the error, but actually I'm just too busy.

- control does not unregister. Thats right and I have pointed that out in the readme. Function DllUnregister is a dummy at that point. But hey, this code is not for beginners and the unregister job isn't that hard for experienced programmers. Just look at the register job in DllRegister.

- the project is large: It isn't really large, but it is splitted in several source files. An active-x control has to support a bunch of interfaces, so it doesn't fit in 10 lines of code.

- documentation lacks: thats true. And actually I dont think I will supply one. So if you are a beginner in COM, you will possibly have some difficulty understanding what's happerning there.



Thats all true. But I have posted this code because:

- the colib licence supplied with masm7.0 is restricted. For commercial software you need to "buy" a licence from Ernie, developping free software using the colib may be problematic.

- in the colib version supplied with masm 7.0 there are some annoying bugs. So for example the main benefit of that code, the "registry script handler", doesnt work in that version.

- all parameters in the colib stuff are "untyped" (defined as simple DWORDS). Very bad for debuggers like that one in VC. In the sample i have posted you easily can watch all member variables or your object.

- the structure of objects generated with colib aren't compatible with VC (which requires that all vtables of all supported interfaces are located at the start of an object, without a "base pointer" between them.



To Ernie: please do not edit this reply. May be that's a nice joke. But I am German and we all totally lacks sense of humour, as you all probably know.


japheth
Posted on 2002-01-11 03:14:35 by japheth
Guys,

I will ask a favour from both of you in this area, programming thrives on variation and in particular assembler programming has its hallmark in difference. If I have it right, Microsoft "own" the idea of COM so it is not really anyones exclusive domain.

Having different approaches to the same field is not without its advantages and having this variation can only be of benefit to those who are interested in the COM field.

All I ask of both of you is that each other will be respected and the differences can be managed in a friendly manner. This way everybody will gain from the dialogue.

Regards,

hutch@movsd.com

PS : Japheth, most Germans I know have an interesting sense of humour, different but not without its virtue, what happened ? :tongue:
Posted on 2002-01-11 05:11:15 by hutch--
Well put Hutch.

My only extra thoughts is why am i reading what should be constructive feedback now? And its not being used as a constructive device, but rather a power stuggle of who's design is most benificial?

I just wish people would post their thoughts like this before it turns into an issue. I do think Ernie is a very understanding person, and to point this out earlier couldnt have done anything but help each other (most likely).

NaN
Posted on 2002-01-11 16:31:09 by NaN
Shall we take them in order?


- - documentation lacks: thats true. And actually I dont think I will supply one. So if you are a beginner in COM, you will possibly have some difficulty understanding what's happerning there.

I'm wondering how this code then rates as a replacement for CoLib, as is implied in the thread topic. Perhaps that was just a bit too boastful on the part of the original poster.



- the colib licence supplied with masm7.0 is restricted. For commercial software you need to "buy" a licence from Ernie, developping free software using the colib may be problematic.

Yeah, I agree. All those popup adds and transaction processing scriptlets on my web page must dog your browser when all you wanna do is read a tut or two of mine.

At this point, CoLib has had a total of ONE full license granted for it, and even that was unasked for. I granted it to someone who made an addition to CoLib, and was so kind to email me his code along with an explanation as to the problem it solved.

Copyrighting my own work is my right. I did it mostly to keep my code out of the CD ROM for the next edition of "Mastering Assembly Super Bible." If this copyright restriction has seriously limited anyone, they have yet to email me about it.

I *have* seen some of my code popping up in other people's work. Maybe you should take a poll of how many of them I have hassled over copyright restriction violations? The answer is zero, no one hears from me. This works against my self-interest, because US copyright law is specific that if a copyright is not "vigorously defended" then it lapses by default.

But I much prefer to see people learning from my work, and actually feel honored when I see I've inspired someone to do something with it.

Finally, if someone should reuse someone else's code in a commercial work, and earns themselves a ton of money over it, wouldn't you think they owe the producer of that code something? If you don't, you truly lack any sort of maturity.

There ain't no such thing as a free lunch.



- developping free software using the colib may be problematic

I want to revisit this minor point to make it crystal clear. "Free software" can hardly be construed to be "commercial use." "Commercial use" means you get PAID for selling something.

If you make some handy helper application and wish to give it away, by all means use CoLib, and with my blessing too!

Geeze, do we need a Clarence Darrow to figure out "I learned something while I wrote this, and I didn't make any money from it cause I'm giving it away" is fair use of code marked: "For educational use only"?



- - in the colib version supplied with masm 7.0 there are some annoying bugs. So for example the main benefit of that code, the "registry script handler", doesnt work in that version.

Polite bug reports are always welcome as they lead to further refinements. As far as the "registry script handler" is concerned, it's always been a known, reported issue. It works enough to suit most needs (one can usually change the elements of a registrar script (not registry script) and usually get it to work. If anyone is really concerned over it, they are free to write their own version.

But if you do write one, PLEASE DO include the uninstaller code. Not only is the uninstaller part of the COM standard, but it is downright RUDE not to put it there.

You think everyone wants your code dogging their machine forever?



- - all parameters in the colib stuff are "untyped" (defined as simple DWORDS). Very bad for debuggers like that one in VC. In the sample i have posted you easily can watch all member variables or your object.

This in intentional and by design and in keeping with MASM32's general method of loose type checking.



- - the structure of objects generated with colib aren't compatible with VC (which requires that all vtables of all supported interfaces are located at the start of an object, without a "base pointer" between them.

Why would you expect them to be? This isn't an extension to VC. It is a library to compliment MASM32 for applications written in assembly. If you want VC objects, use VC!

As far as using these COM objects from a VC app, as long as you do so through the COM interfaces it will work. COM is a binary standard communications between applications, and CoLib upholds that standard 100%

No where no how was it ever intended to enforce VC's method of defining objects.



- To Ernie: please do not edit this reply. May be that's a nice joke. But I am German and we all totally lacks sense of humour, as you all probably know.

Rattling the cage of humorless people is one of the most sportingly fun things one may do on the net. Please don't make it overly tempting for me.

As far as leaving little j's rude posts, not to worry, I shall never again edit them.

I will simply delete them.






To japheth: Never assume you are the prototypical person. I'm 3/4 German ancestry and cannot remember anyone in my lineage that lacked any of the basic human traits. And yes, you have demonstrated one may write a large app completely by hand, re-writing the same code over and over.

<golf course clap inserted here>

So what do you think the next step is, some student starving for knowledge will study your code endlessly until by divine inspiration he gets the WHY and HOW it works?

If you wish to author another COM in ASM standard, then do so. Don't pretend you have already done so just because you have some code that seems to work.

The documentation you care nothing for is the difference.

All you have here is a "don't you love my code?" posting.
Posted on 2002-01-11 21:11:36 by Ernie
This is an interesting set of posts and one should never butt into anothers conversation but I have one thing to say:

I believe that J's original intent was not to dethrown E or take glory from anyone but that it came across as a communication difference. Rather than shooting arrows for sport lets just act curtious towards one another.

It's one thing when two members have a difference. It's another thing when I mod is on the defensive side of the fence as it gives off the wrong message (unless it's for the right reason) and IMHO, this isn't the right reason.


Thanks,
_Shawn
Posted on 2002-01-11 22:04:52 by _Shawn
_Shawn, that was defensive?

Ernie, thanks for the wit.

japheth, thanks for the example.

Hutch--, good advice.

Much to be learnt in this thread. :grin:
Posted on 2002-01-11 23:07:47 by bitRAKE
... unless it suddenly disappears.
Posted on 2002-01-12 02:31:33 by f0dder
f0dder:

unless it suddenly disappears


That's EVIL!!! :grin:
Posted on 2002-01-12 03:21:36 by Qweerdy
Qweerdy, indeed it is. I wish those two would stop fighting, *sigh*.
Posted on 2002-01-12 04:38:52 by f0dder
Hi,

Ernie, you have convinced me not providing an unregister function is rude. So I added one. Thank you very much for pointing that out.

To unregister execute "regsvr32 /u AsmCtrl.ocx". This will unregister any old version too, since the CLSID hasn't changed.

And one point I have forgotten to mention: This sample is some sort of conversion of Ernies sample "AsmCtrl" from his colib.zip. Parts of the original code are still included. Just in case you haven't look at this corner of the masm32 package until now.

The IE explorer crash seems to have vanished, at least with my version of IE (5.5). I don't know why :) .

japheth
Posted on 2002-01-12 08:23:13 by japheth
I understand Ernie's concern with commercial exploitation of the code that he has written and it is for the same reason that I have copyrighted the entire content of MASM32. After many offers to commercialise MASM32 "Hey man, I/we can market your product to ...", "Oh BTW, can I add MASM32 to the appendix of the CD for my new book" I chose to completely close the door on further offers with the copyright that MASM32 currently has.

This allows programmers to write their own commercial code using the contents that I have written myself without any form of royalties or costs but protects the content from any form of commercial exploitation.

My intention was to ensure that any programmer who was interested in writing assembler could obtain the package without being beholding to anyone or dependent on other peoples commercial considerations.

With contributed code, the consideration was that it was available to programmers for non-commercial use without cost. It is reasonable that when someone contributes code that it is not commercially exploited without their approval so the overall copyright for MASM32 protects the code from that type of usage and if someone is interested, they can contact the author.

Regards,

hutch@movsd.com
Posted on 2002-01-12 17:36:26 by hutch--

his allows programmers to write their own commercial code using the contents that I have written myself without any form of royalties or costs but protects the content from any form of commercial exploitation.

If I read it right, this is very fair usage. People trying to sell the
masm32 package would be bastards anyway. However, masm32
on some magazine front-cover CD? Dunno... could greatly increase
the knowledge of masm32 (for good and evil). I had a program of
mine on the walnut creek CD. Got a lot more useless mails from AOL,
but also some good mails from various people (and even found out
that at least two AOL users weren't total idiots, but quite nice and
intelligent and whatnot ;)).
Posted on 2002-01-12 20:26:25 by f0dder