|
Hi,
i want to return a collection from my ATL-Component to Simple VBAppl. I
have gone through the example of MSDN in which it is using the Interface
"ICollectionOnSTLImpl ", but in that Example it is returning a particular
value as per the given Index or key and i am looking for returning whole
collection.
There is Data member "m_coll" of "ICollectionOnSTLImpl" it holds the
collection values. Is there any way to return "m_coll" from ATL-Component
? or any other way to return Collection type from COM.
Thanking you,
Regards,
Shailaja
|
|
|
|
|
You don't return a collection, a collection is only for holding and iterating through items. What you want is a SAFEARRAY. See Q207931[^] for some sample code. Scenario 3 in the article is the one that applies to your situation.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
This class may also be helpful
http://www.codeproject.com/cpp/VariantArray.asp
|
|
|
|
|
Once upon a time I tried wrapping my head around MFC. In the end I decided that I hated it. Perhaps I didn't spend enough time with it but how much time does one really need to make a hello world?
Then I found ATL. I liked ATL because it was small and made sense it even had a windowing system to make gui apps with called "ATL Window Classes." They were great and supported by Microsoft.
Then came WTL. I found it when it was called 3.1 and I fell in love. It is just the extension to the ATL Window classes. In fact they are exactly the same at the root level. WTL just adds a whole bunch of new wrappers to bring the controls up to date.
Granted the lack of true documentation makes it a tad more difficult but any one who has done raw Win32 API programming will find the controls very similar. To find out the parameters all one has to do is find out what the WTL is wrapping and there you have it - Documenation.
The WTL support groups are also fantastic. They have always had an answer for me when I need them.
Three cheers for WTL!
|
|
|
|
|
I love it to, you need to know your c++ and the win32 api, then everything works like a charm.
MFC just adds a lot of limitations and wierd behaviour you have to work around.
/M
- Don't sweat the petty things, and don't pet the sweaty things.
|
|
|
|
|
Yay! My sentiments exactly. Having started Windows programming back in the dark days of Win16 (3.0/3.1) I have found WTL easy to use and being template based, extremely flexible. I don't think enough emphasis has been placed on the fact the library is a collection of C++ templates - which is a far more flexible approach than monolithic MFC.
Actually, I know one or two developers that won't go near WTL because they find C++ template programming too difficult! Madness.
So, hip-hip hooray for WTL. Nenad deserves a medal for his hard work.
Faith. Believing in something you *know* isn't true.
|
|
|
|
|
I've been developing in WTL for a few months and have submitted a few articles to CP. However, I'm wondering whether to scrap WTL and jump on the C# bandwagon. I'm starting to feel left behind. Most of the new articles seem to be C#/MC++/.NET.sucks stuff. I bought into fading technology once or twice in the past and got burned. Is WTL dying?
|
|
|
|
|
It has its own place. You don't need to give up anything to learn anything new. What is the problem in learning everything managed - unmanaged stuff?
|
|
|
|
|
It is possible to waste a lot of time learning things that are not productive. There are only so many days in a year and I need to pursue marketable skills.
|
|
|
|
|
WTL and .NET are two entirely different animals. There's no way to answer "which one should I use?" without knowing what you want to do. It's just like asking "Should I use MFC or .NET?".
As for whether it's dying... well, I don't know if it was ever really "living". It's always been an underground type of library, although I personally like it, and MS updated it recently to version 7 (which you can happily use with VC6).
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I'm writing a personal credit manager for home PC users. It is pure client-based and (I think) a prime candidate for WTL. Multi-tier? No way. Web services? In the future, it may require a web link to obtain updated bank rates but that's for a future release.
Thanks for your response, Michael.
|
|
|
|
|
WTL was never born. It's a side project from a single Microsoft employee, and has been officially denounced by Microsoft. (http://windows.oreilly.com/news/visualc_0500.html[^])
I wasted 6 months on WTL.. it's going nowhere. Don't you make the same mistake!!
|
|
|
|
|
Dude, update your references. That interview pre-dates WTL 7, so MS has actively worked on it and updated it. And for something that was allegedly an accidental release and about to be recalled, it sure seems to be readily available as a download from (of all places) MSDN.
Again, any claims of having wasted time with it are meaningless without stating what you wanted to do with it in the first place.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
You are misinformed. Switched back to MFC then have you? Think there will be an MFC8? Mmmm. I don't think there will be. If .NET doesn't take off (and the jury is still out) then WTL will be the best way to code C++ Windows apps for a long time to come...
When I am king, you will be first against the wall.
|
|
|
|
|
Yeah, I switched back to MFC. I don't care about an MFC 8; in fact, I don't even care about MFC 7 (it has no real advantacges over 4.x, as fas as I'm concerned.)
The differences are that MFC is mature and complete, and WTL is stillborn and incomplete. I mean, come on; WTL doesn't even have documentation! When I was doing my WTL project (a graphics library that was supposed to form the eventual basis of an application), I had to continually look at the message handler prototypes to figure out what functions I needed to call. And they were _just_ enough different from MFC that I could never quite remember them.
Why WTL is still included in the SDK is beyond me; presumably as a sop to the few people who are using it. Yes, if .NET fails, MS will need to build a modern class library, and WTL _could_ be it (its heavy dependence on macros is a strike against it, but it's still pretty interesting.) I'm no .NET fan, but how much chance do you think there is that MS will change direction?
|
|
|
|
|
how much chance do you think there is that MS will change direction?
A good chance. MS is very market savvy. That's why they are producing .J2EE, er, I mean, .NET now. If it fails, they will adapt.
I appreciate your response to my original question. I'd hate to waste too much time on a technology loser.
|
|
|
|
|
Jim A. Johnson wrote:
stillborn and incomplete
Hence the recent update to WTL7 earlier this year? Incomplete? It's supposed to be light - that's part of the appeal. Besides, once you bring ATL7 into play (after all, WTL was designed as an extension to ATL) then I find there are plenty of classes. Even MFC7 shares the ATL7 CStringT template, plus you get file handling, server code (SMTP classes, MIME classes), etc. etc. Together I think that ATL/WTL makes for a VERY complete library indeed. ATL is well documented too.
OK, a lack of "offical" docs may put people off but there are excellent docs available off the web. Top tip: Add the dozen or so WTL headers to your project, and you can browse WTL objects using ClassView.
As for any direction change, who knows. Something like 60% (possibly higher) of our customer base are still using Win9x - how will me coding my apps in C#/.NET help them? Are they all likely to move to 2000/XP en-masse? Not yet they're not. I don't think .NET will be important to many developers for a few years yet. It depends on the business you are in I guess.
Such a pretty house, such a pretty garden.
|
|
|
|
|
Robert Edward Caldecott wrote:
Hence the recent update to WTL7 earlier this year?
I haven't compared the two: I gave up on WTL before VC7 came out - but I feel I can't make this point strongly enough: the lack of documentation is a clear sign that this is not a serious project. If there are good docs on the web, I have yet to find them.. the WTL docs here are also incomplete.
Don't get me wrong: I really, really would like to see MS come out with a next-generation desktop framework. I have no use for .NET, and am really ticked off at the deprecation of C++ and MFC in the latest version of the IDE. But without official support, WTL will never thrive.
|
|
|
|
|
I find WTL more intuitive than MFC and it is a lot easier to extend. MFC changes many of the features that the WIN32 API implements in order to get it's special message handling into place. A modal dialog box is a good example of this.
While there is no official documentation for WTL, if you are familiar with the Win32 API, it is a breeze. Most of the function calls are simple inline wrappers. And the ones that aren't like the GDI classes, they only make things easier.
I think that it is perfectly acceptable to continue using WTL, because of the support from the developer communites that use WTL, and the fact that you have the 20 header files that it is completely contained. So as long as WIN32 applications are in style, WTL can be in style as well.
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!
|
|
|
|
|
Ed Gadziemski wrote:
Is WTL dying?
I don't think so. Besides, it's just a collection of C++ templates in header files - even if Nenad is pulled off the project, I think someone else would take it on - it wouldn't be hard to maintain.
As long as I have customers using Win9x and NT4, then .NET/C# is no good for me. I am also unsure that .NET has the backing that MS were expecting - time will tell. Always use the best tool for the job - and right now, WTL is the best tool for writing typical client Windows apps IMHO.
Besides Ed, I have seen your articles and they ROCK! WTL needs people like you! The more people using it, the better. MS admitted they were surprised at how popular WTL is, so we need to keep shouting about how good it is!
Kicking, squealing Gucci little piggy.
|
|
|
|
|
Thanks! I think WTL is great and hope it continues. I just don't want to get caught on the trailing edge again. My software losers: Quick Basic, Uniface, FoxPro, PowerBuilder, Power++..... My hardware losers: Amstrad, Packard Bell, Prime, DEC.....
|
|
|
|
|
Ed Gadziemski wrote:
Amstrad
Amstrad! *cough*
Faith. Believing in something you *know* isn't true.
|
|
|
|
|
I agree with Jim. WTL, as a technology, is clearly superior to MFC (and I think to .NET). However, it is incomplete, undocumented, and not at all certain to become MFC's ultimate replacement. MS has put the weight of their company behind .NET. Currently, it is the best bet for moving beyond MFC.
I'm not a real reverend, I just play one on CP.
|
|
|
|
|
I think that it is perfectly acceptable to continue using WTL, because of the support from the developer communites that use WTL, and the fact that you have the 20 header files that it is completely contained. So as long as WIN32 applications are in style, WTL can be in style as well.
I am currently working on an game written with DirectX and WTL. I have been able to do everything that I wanted to do so far. I needed a more efficient message pump object than the original one that came with WTL, so I wrote one and plugged it into WTL. Works like a charm. (I also wrote an article about it here on CP, called WTL Game Loop).
WTL has its place, if you are moving on to .Net then this isn't for you. If you are staying with client based applications on a windows PC, I think this is a great choice.
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!
|
|
|
|
|