MFC vc ATL
Raja Segar -- rsz@pc.jaring.my
Thursday, November 28, 1996
Environment : VC++ 4.2b Patched, Win95, NT 4.0
SUBJECT : MFC vs Active Template Library (ATL)
On the subject above, i don't know if any of you have heard
about ATL being tounted speedier replacement of MFC.
I recall reading an article in VBPJ that mentioned that ActiveX
components built around MFC are bulky, slow and need those
huge run time libraries as compared to slim, fast and efficient
control built using ATL. Even Visual Basic 5 is rumoured to
abandoning it's dependency on MFC and turning to ATL.
If MFC is slow & bulky , what is the cause ot his behaviour ?
Too comprehensive?
Is there any weight in all this romours. If yes how it going
to effect us MFC fans. Are we doomed or are we going to blend MFC &
ATL to our programs.
BTW is ATL a total replacement of MFC or is it just the OLE part ?
Can someone please clarify this.
I leave to someone knowledgable on this subject to comment.
So ...
Anyway i would like to all those people who replied to my
question on UNICODE support. Thanks a lot guys, you'll were a great
help. Keep it up.
Bye & take care.
( _ \/ __)(_ )
) /\__ \ / /_
(_)\_)(___/(____)@pc.jaring.my
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, November 30, 1996
At 20:09 11/28/96 +0800, Raja Segar wrote:
>SUBJECT : MFC vs Active Template Library (ATL)
>On the subject above, i don't know if any of you have heard
>about ATL being tounted speedier replacement of MFC.
Who is touting it as that? Where, speicifcally, did you read
about that?
>I recall reading an article in VBPJ that mentioned that ActiveX
>components built around MFC are bulky, slow and need those
>huge run time libraries as compared to slim, fast and efficient
>control built using ATL.
If you compare the size of an OLE control built with ATL with
the size of an ATL control in MFC, you'll find that they're
really very similar-- _IF_ you implement the same features. Most
people don't implement the same features when they spout off about
these kinds of comparisons, so the comparisons don't really make
much sense.
>Even Visual Basic 5 is rumoured to
>abandoning it's dependency on MFC and turning to ATL.
No. That's simply fiction. Where did you hear that?
>If MFC is slow & bulky , what is the cause ot his behaviour ?
>Too comprehensive?
What is the cause of what behaviour? MFC's bulk? Assuming that's
what you mean: yes, MFC is big because it does an immense amount
of work for you.
ATL does very very little for you. While it is very easy to make
a COM object using ATL, it's not very easy to make a full-fleged
OLE Control using ATL. ATL doesn't, for example, help you implement
stock properties, property pages, or do drawing or serialization
the way that MFC does.
Features must be implemented in code. Code exists: it has mass
and takes up space, and you have to do that somewhere.
As MFC moves forward, we are (I am) working on ways to trim down
its working set without ruining compatibility or removing features.
>Is there any weight in all this romours.
No. I'm glad you admitted that they're rumours: your first paragraph
makes it sound like you're stating a fact... and there's nothing
further from the truth. MFC and ATL are not competing technologies,
so saying something like "MFC vs ATL" is really nonsensical.
>If yes how it going to effect us MFC fans. Are we doomed or
>are we going to blend MFC & ATL to our programs.
Eventually, it might not be a bad idea. Here, eventually means "in the next
three years". There are clear places where MFC is far more appropriate than
ATL, and there are clear places where ATL wins. This speculation is tied to
the plans Microsoft has for making the operating system itself far more
COM aware.
>BTW is ATL a total replacement of MFC or is it just the OLE part ?
Have you even looked at ATL? Even the most cursory examination of
it reveals that it isn't a replacement for MFC. ATL is a tool that
makes the _implementation_ of COM components pretty easy. MFC
makes the implementation of entire applications, including all of
their user interface components, very easy. MFC is large because it
actually _implements_ those things; ATL is small because it implements
(nearly) nothing. One part of MFC allows you to _use_ COM objects
very easily. It's easy to _implement_ a COM object in MFC, but doing
so buys into the girth of MFC.
In some situations, that's appropriate: if your COM object is a huge
spreadsheet or a dialog that does some complicated database activity,
MFC is the obvious choice. If you're implementing a tiny object that
you want to throw around on a network, ATL might be a better idea.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
Tim Lesher -- timl@epix.net
Saturday, November 30, 1996
> On the subject above, i don't know if any of you have heard
> about ATL being tounted speedier replacement of MFC.
Whoa! That's a pretty sweeping statement, and reminds me of the person who
tried to tell me that C++ is obsolete, now that we have Java (or Dylan, or
Eiffel, or ...).
> If MFC is slow & bulky , what is the cause ot his behaviour ?
MFC is unwieldy for writing straight COM objects simply because it isn't
meant for writing straight COM objects. It's tuned for writing
applications based on the document/view metaphor, with extensions for
ActiveX controls. MFC is as bad for writing COM objects as the ATL is for
writing applications.
You have to use the tool that works best for the problem. For example, the
ActiveMovie C++ class library doesn't use a lick of MFC--in fact, you can't
use MFC in ActiveMovie objects. It's just not a good fit. Just because
you have a hammer, don't make the mistake of thinking everything's a nail.
> BTW is ATL a total replacement of MFC or is it just the OLE part ?
> Can someone please clarify this.
No--ATL does NOT replace MFC, in any way, shape, or form!
Why not Read The Friendly Manual? (Or at least the Web page, at
http://www.microsoft.com/visualc/v42/atl/default.htm). Here's what the
Microsoft white papers have to say:
ATL is focused entirely on the creation of small, fast COM servers in C++.
It is optimized for the creation of objects that expose custom or dual
interfaces and has absolutely no inherent support for more complex
COM-based architectures, such as ActiveX Documents. Of course, because it
is purely C++ source code that helps you to implement a COM substrate,
there is nothing to stop you from building anything you choose. But why
bother, when there are frameworks and libraries whose prime purpose is to
make the creation of those more complex things simpler? For example, the
Microsoft Foundation Class Library (MFC) is an excellent C++ framework for
creating advanced OLE and ActiveX-based applications, including ActiveX
controls, ActiveX Documents and regular embedded and linked objects. To
build them with ATL would require a very significant amount of work, for
relatively little gain. MFC contains standard, customizable implementations
of the major OLE and ActiveX interfaces and the logic around their use,
making it fairly simple to add, for example, the ability to host ActiveX
controls in an MFC application, or to create an application which allows
other applications to embed objects within it. Taking ActiveX controls as a
specific area of functionality, two frameworks exist from Microsoft at
present for their creation. The first, MFC, provides an easy way to write
fully functional controls. If you are prepared to put in more effort and
don't mind having to understand a lot more about how controls and COM
operate, then you can choose to use the ActiveX BaseCtl framework that
ships with the ActiveX SDK. If you want to create generic COM objects or
OLE automation objects with dual interface support, or intend to support
COM's free-threading model (available with Windows NT? 4.0 and later
versions of Windows?), and you don't have a significant user interface in
your object, then ATL is the choice for producing the smallest, fastest
code.
Tim Lesher
timl@epix.net
Frank McGeough -- fm@synchrologic.com
Saturday, November 30, 1996
> Environment : VC++ 4.2b Patched, Win95, NT 4.0
>
> On the subject above, i don't know if any of you have heard
> about ATL being tounted speedier replacement of MFC.
> I recall reading an article in VBPJ that mentioned that ActiveX
> components built around MFC are bulky, slow and need those
> huge run time libraries as compared to slim, fast and efficient
> control built using ATL. Even Visual Basic 5 is rumoured to
> abandoning it's dependency on MFC and turning to ATL.
>
> If MFC is slow & bulky , what is the cause ot his behaviour ?
> Too comprehensive?
>
> Is there any weight in all this romours. If yes how it going
> to effect us MFC fans. Are we doomed or are we going to blend MFC &
> ATL to our programs.
ATL is not an MFC replacement. ATL is useful for building smaller
footprint COM objects. Neither one is a panacea, each is a
tool and should be evaluated against the problem that you're trying
to solve.
ATL is not necessarily small footprint either. Since it's using templates
it is subject to the same problems of template bloat found in
using the C++ STL.
I use the ATL to build separate COM objects that I use both from
HTML & Java in a browser and from MFC or Delphi standalone apps.
I would suggest that you visit the Active X Web Site and download
the ATL 1.1 which now comes with documentation and a white paper
as a starting point.
George V. Reilly -- georger@microcrafts.com
Saturday, November 30, 1996
>Raja Segar[SMTP:rsz@pc.jaring.my] writes:
>On the subject above, i don't know if any of you have heard
>about ATL being tounted speedier replacement of MFC.
>
>I recall reading an article in VBPJ that mentioned that ActiveX
>components built around MFC are bulky, slow and need those
>huge run time libraries as compared to slim, fast and efficient
>control built using ATL. Even Visual Basic 5 is rumoured to
>abandoning it's dependency on MFC and turning to ATL.
>
>If MFC is slow & bulky , what is the cause ot his behaviour ?
>Too comprehensive?
>
>Is there any weight in all this romours. If yes how it going
>to effect us MFC fans. Are we doomed or are we going to blend MFC &
>ATL to our programs.
>
>BTW is ATL a total replacement of MFC or is it just the OLE part ?
>Can someone please clarify this.
I've written a few objects for Denali (Microsoft's Active[X] Server
Pages),
some with MFC, some with ATL.
ATL is intended just for writing ActiveX objects, which are lightweight
OLE Automation objects. Version 1.1, which is available from
http://www.microsoft.com/visualc/v42/atl/default.htm , doesn't really
support full-fledged OLE Controls. Version 2.0, which should be
going into beta soon, will. There are still large areas of OLE which
it won't support, such as OLE containers. ATL is lean and mean,
so you have to do much more by hand than you would with MFC.
MFC, on the other hand, takes the kitchen-sink approach and
supports very nearly anything you'd want to do with Windows
programming, including OLE. Consequently, it's pretty big and
that's a definite problem if you're trying to write a small object
that can be downloaded to the user's browser. If you send them
an extra megabyte of MFC DLLs over a 28.8 modem, they
won't thank you for it.
ATL adds about a 20Kb overhead to the size of an object, which
is far more acceptable. If you replaced the 20Kb of ATL code with
your own handrolled OLE code, you probably wouldn't appreciably
reduce the size of your object.
You can use both ATL and MFC simultaneously, but I'm not sure
why you'd want to.
MFC is still an appropriate solution for most kinds of Windows
programming, and I can't see Microsoft dumping it anytime soon.
>--
>/George V. Reilly
>MicroCrafts, Inc., 17371 NE 67th Ct #205, Redmond, WA 98052, USA.
>Tel: 206/250-0014 Fax: 250-0100 Web: http://www.microcrafts.com
>Vim 4 (vi clone) for NT & Windows 95: http://www.halcyon.com/gvr/
>pgp fingerprint: e2 b4 83 64 11 52 21 ea bf d8 51 c2 11 00 78 fc
Claus Michelsen -- clausm@vip.cybercity.dk
Sunday, December 01, 1996
ATL is only used for certain parts of OLE such as COM and Automation. It =
has no support for more high level OLE stuff such as OLE Documents. ATL =
is meant to be used only for the really low level OLE things and will =
therefore not replace MFC. You can actually use it together with MFC if =
you want to. It is just another tool at your disposal.
Best regards,
Claus Michelsen
-----Original Message-----
From: Raja Segar [SMTP:rsz@pc.jaring.my]
Sent: 28. november 1996 13:10
To: mfc-l@netcom.com
Subject: MFC vc ATL
Environment : VC++ 4.2b Patched, Win95, NT 4.0
SUBJECT : MFC vs Active Template Library (ATL)
On the subject above, i don't know if any of you have heard
about ATL being tounted speedier replacement of MFC.
I recall reading an article in VBPJ that mentioned that ActiveX
components built around MFC are bulky, slow and need those
huge run time libraries as compared to slim, fast and efficient
control built using ATL. Even Visual Basic 5 is rumoured to=20
abandoning it's dependency on MFC and turning to ATL.
If MFC is slow & bulky , what is the cause ot his behaviour ?
Too comprehensive?=20
Is there any weight in all this romours. If yes how it going
to effect us MFC fans. Are we doomed or are we going to blend MFC &=20
ATL to our programs.=20
BTW is ATL a total replacement of MFC or is it just the OLE part ?
Can someone please clarify this.
I leave to someone knowledgable on this subject to comment.
So ...
Anyway i would like to all those people who replied to my
question on UNICODE support. Thanks a lot guys, you'll were a great
help. Keep it up.
Bye & take care.
( _ \/ __)(_ )
) /\__ \ / /_=20
(_)\_)(___/(____)@pc.jaring.my
Doug Robb -- doug@psy.uwa.edu.au
Monday, December 02, 1996
Let me put my disclaimer first: I haven't read any
info an the ATL and so can't comment on that part of
Raja's questions. I've used MFC for a couple of years
now.
On Thu, 28 Nov 1996, Raja Segar wrote:
>
> If MFC is slow & bulky , what is the cause ot his behaviour ?
> Too comprehensive?
>
I didn't know that it was (slow and bulky). Most of the books ref's etc
say mfc is a wrapper (usually quite thin) to the underlying
win C API's. Terms like 'slow and bulky' seem inappropriate
when mfc applications (which are essentially C++ apps)
run at light speed compared to VB apps and java apps
for that matter .....
> BTW is ATL a total replacement of MFC or is it just the OLE part ?
> Can someone please clarify this.
I would imagine we are only talking ole, now ActiveX. Apart
from straight C, C++ (and assembly) MFC produces the fastest
code by a long shot compared to the other alternatives
to developing windows apps. The productivity of MFC programmers
is getting to the stage in my opinion to be equal to that
of VB, albeit there is a pretty steep learning curve to
master it.
Lets face it if speed is your only consideration you'd
write components is assembly languages but then when you
plugged them into a much slower environment (like VB and java)
you haven't gained anything have you? Its better to be able to
be able to easily make components ..... which mfc lets you do.
regards doug
Email - doug@psy.uwa.edu.au ,-_|\ Doug Robb
Phone - +61 9 380 2507 / \ Senior Analyst Programmer
Fax - +61 9 386 7564 --> *_,-._/ Psychology Department
v University of Western Australia
>From U.S. 011-61-9-380-2507 (EST +12hrs)
from U.S. 011-61-9-386-7564
Homepage: http://www.psy.uwa.edu.au/user/doug/doug.html
=========================================================================
Scott Colestock -- scolestock@wavefront.com
Monday, December 02, 1996
Gosh, I'd have to disagree....I think that MFC makes writing straight =
COM objects pretty painless. CCmdTarget has everything you need. The =
whole BEGIN/END_INTERFACE_PART macro setup along with the data-driven =
QueryInterface implementation (through the INTERFACE_PART macros) is =
fairly straight-forward. Support for aggregation is there, & dual =
interfaces really aren't any harder than they are with ATL - I've tried =
both.
Check out (if you haven't already) Technotes 38 & 65.
- Scott
>MFC is unwieldy for writing straight COM objects simply because it =
isn't=20
>meant for writing straight COM objects. It's tuned for writing=20
>pplications based on the document/view metaphor, with extensions for=20
>ActiveX controls. MFC is as bad for writing COM objects as the ATL is =
for=20
>writing applications.
Dean Wiles -- deanw@isc-br.isc-br.com
Monday, December 02, 1996
> >If MFC is slow & bulky , what is the cause ot his behaviour ?
> >Too comprehensive?
>
> What is the cause of what behaviour? MFC's bulk? Assuming that's
> what you mean: yes, MFC is big because it does an immense amount
> of work for you.
>
> ATL does very very little for you. While it is very easy to make
> a COM object using ATL, it's not very easy to make a full-fleged
> OLE Control using ATL. ATL doesn't, for example, help you implement
> stock properties, property pages, or do drawing or serialization
> the way that MFC does.
>
> Features must be implemented in code. Code exists: it has mass
> and takes up space, and you have to do that somewhere.
>
> As MFC moves forward, we are (I am) working on ways to trim down
> its working set without ruining compatibility or removing features.
>
1) Is there any reasonable way of extracting specific classes from MFC for
use in a light-weight, non-GUI COM server? MFC has some great classes (eg:
CString and the CDatabase/CRecordset classes) that we'd like to use in some
2- and 3-tiered applications accessed via OLE/COM. Unfortunately, most MFC
classes seem pretty intertwined with the AFX core. Are these available
individually or should I be looking at someone else's class library
(although I'd really rather stick with one family of classes)?
2) As an OLE/COM newbie, the ATL documentation is difficult to follow.
There is a lot of new terminology and concepts which are defined in terms
of themselves. Some examples in the doc, or references in the doc to
specifics in the example code would be helpful.
3) Wizard support for or examples of ATL (and MFC for that matter) that
can be used from Visual Basic would be really helpful. What I mean is OLE
features that are easily implemented in VB that are difficult or obscure in
an MFC or ATL project:
a) Class Wizard support for dual interfaces methods and properties
(more than just IDispatch).
b) Support for Named and Optional parameters in Methods.
c) Do you use BOOL, boolean, VARIANT_BOOL, or what so that VB treats
input and output parameters as BOOLean?
d) Implementation of OLE interface help - not just "helpstring", but
also "helpfile" and "helpcontext" and where they hook in.
e) Examples or doc for proper OLE Exception handling.
f) What version numbers, GUID's, Typelibs, naming conventions, etc need
to be changed when an interface changes?
g) Complete registration and unregistration of server interfaces
(including embedded TypeLib info) so that it's visible in VB's
Tools/Reference list.
h) An automatic way to bump VersionInfo/FileVersion resources so that
installation detects newer or older versions.
Although I don't like VB a whole lot, reality is that a lot of (our) OLE
clients will be VB, and their development environment has done much to make
OLE implementation easier for the developer.
As developers, we want to leverage the bleeding edge technologies that are
coming from Redmond. Answers to the above questions and/or enhancements to
Developer Studio, MFC, and ATL could assist developers in keeping up with
the pace and correctly implementing these new technologies.
Thanks, Dean.
--------------------------------------------------------------------------
Dean Wiles (deanw@mail.isc-br.com) Olivetti North America
Phone: (509)927-7037 22425 East Appleway Ave
Fax: (509)927-2499 Liberty Lake, WA 99019-9534
If the Son sets you free, you will be free indeed. (John 8:36)
Randy Sales -- rsc@halcyon.com
Wednesday, December 04, 1996
Scott Colestock wrote:
>
> Gosh, I'd have to disagree....I think that MFC makes writing straight =
> COM objects pretty painless. CCmdTarget has everything you need. The =
> whole BEGIN/END_INTERFACE_PART macro setup along with the data-driven =
> QueryInterface implementation (through the INTERFACE_PART macros) is =
> fairly straight-forward. Support for aggregation is there, & dual =
> interfaces really aren't any harder than they are with ATL - I've tried =
> both.
> Check out (if you haven't already) Technotes 38 & 65.
>
> - Scott
>
Scott, thanks for the viewpoint. I have not had the pleasure yet of
writing a server using ATL, only MFC. My only experience in writing
COM objects has been using the MFC and CCmdTarget. But it was surprisingly
easy, albeit somewhat poorly documented. It was, infact, one of the
highlights of my past year to find that using COM objects to partition an
application was easier than "advertised" when using the MFC. While the
same objects might have been less bulky using ATL, they might also have
never gotten developed in the time available.
Randy Sales
--
RS Consulting
1521 1/2 Cedar Street
Everett, WA 98201
Phone 206-259-1056
Fax 206-259-1315
email rsc@halcyon.com
Tim Lesher -- timl@epix.net
Wednesday, December 04, 1996
[Mini-digest: 2 responses]
>>MFC is unwieldy for writing straight COM objects simply because it isn't
>>meant for writing straight COM objects.
>Gosh, I'd have to disagree....I think that MFC makes writing straight
>COM objects pretty painless.
It's not the actual _coding_ of COM objects that is unwieldy under
MFC--it's the implementation and delivery aspect. I usually prefer to
implement multiple interfaces on an object by multiply inheriting from the
interfaces, the way Microsoft does it in its ActiveMovie class library.
MFC doesn't do it this way--it nests classes.
Also, to deliver a COM object based on MFC, you have to either link with
the static MFC libraries (resulting in a large object for people to have to
download), or link with the MFC DLLs (resulting in more large objects for
people to download--most users aren't savvy enough to know whether they
have the right versions of MFC DLLs).
[ObMFC] MFC has become a Swiss Army knife library. I would estimate that
80% of the functionality included in MFC isn't used by a given program, and
currently there's no way to incorporate just the bits you need. It would
be really interesting to have multiple, small, independent MFC DLLs, loaded
dynamically, and have some initialization code in MFC that is capable of
printing a coherent message if one or more of the required DLLs for an
application is missing.
Tim Lesher
timl@epix.net
-----From: Mike Blaszczak
At 09:31 12/2/96 -0800, Dean Wiles wrote:
>Are these available
>individually or should I be looking at someone else's class library
>(although I'd really rather stick with one family of classes)?
I'm afraid I really don't have the energy to deal with loaded questions
like this one.
>As developers, we want to leverage the bleeding edge technologies that are
>coming from Redmond. Answers to the above questions and/or enhancements to
>Developer Studio, MFC, and ATL could assist developers in keeping up with
>the pace and correctly implementing these new technologies.
The only question you asked was very antagonisticly posed, so I'm not
going to answer it. The rest of your note involved lots of different
suggestions.
Your item (2) was largely about the documentation, but didn't offer
anything specific. You should put together some specific ideas and fire
them off to vcdocs@microsoft.com. The documentation team loves to hear
what coustomers would like to have more easily found or differently
organized. If you have suggestions for glossary entries or specific
new overview topics, write them up and fire them off.
The rest of your note, that is, section (3), seems to contain requests
for features. You should write to msvc@microsoft.com with your ideas;
that's really the most appropriate way to contact the people who
make decisions for the product. Certainly, mfc-l is the _least_
appropriate way to do that.
Some of the things you list in section (3) are technical questions.
3c) and 3e) and 3f) are already documented in the OLE SDK books and
various articles on MSDN, for example.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, December 07, 1996
At 10:31 12/4/96 -0500, Tim Lesher wrote:
>[ObMFC] MFC has become a Swiss Army knife library. I would estimate that
>80% of the functionality included in MFC isn't used by a given program, and
>currently there's no way to incorporate just the bits you need.
Yes, there is: statically link. If you cruise through the resulting map file,
you'll see that you don't get things you don't use. There are some extreme
situations where you _will_ link a bunch of other things you don't need,
but those situations aren't at all common.
MFC does lots (lots!) more work than people realize; it is a very deep
library.
>It would
>be really interesting to have multiple, small, independent MFC DLLs, loaded
>dynamically, and have some initialization code in MFC that is capable of
>printing a coherent message if one or more of the required DLLs for an
>application is missing.
MFC versions 3.x and earlier were like that. The initialization time of
the multiple DLLs actually turns out to be quite an issue. Further, Windows
doesn't guarantee a loading or unloading order for DLLs in the same process,
and the use of many interdependent DLLs causes lots of obscure problems.
The MFC DLLs would necessarily be heavily interdependent because MFC is
implemented in MFC.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
-----From: "P.J. Tezza"
>Also, to deliver a COM object based on MFC, you have to either link =
with=20
>the static MFC libraries (resulting in a large object for people to =
have to=20
>download), or link with the MFC DLLs (resulting in more large objects =
for=20
>people to download--most users aren't savvy enough to know whether they =
>have the right versions of MFC DLLs).
>[ObMFC] MFC has become a Swiss Army knife library. I would estimate =
that=20
>80% of the functionality included in MFC isn't used by a given program, =
and=20
>currently there's no way to incorporate just the bits you need. It =
would=20
>be really interesting to have multiple, small, independent MFC DLLs, =
loaded=20
>dynamically, and have some initialization code in MFC that is capable =
of=20
>printing a coherent message if one or more of the required DLLs for an=20
>application is missing.
Another alternative for avoiding downloading the MFC libraries (and =
other shared components and files) is to download a setup application =
which knows how look and see if the MFC libraries are needed. The setup =
application would download the MFC libraries only when they are =
required. Often the user already has the MFC files on his system. There =
is a small amount of support for this with the component download =
support built into Internet Explorer. I designed my companies' MFC setup =
toolkit for this scenario, and I plan to add this feature to our next =
release.
PJ
pj@exemplarsoftware.com
www.exemplarsoftware.com
| Вернуться в корень Архива
|