By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,454 Members | 3,191 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,454 IT Pros & Developers. It's quick & easy.

Require some feedback regarding using tree - list- view in Access XP

P: n/a
Hi there

I have avoided to use active x controls because I thought they are causing
more problems then they are doing any good.

I a new application I would want to use the tree and list view control in
access 2002. Prior to that I like to fine some information or here some feed
back from developers who have use active x controls success fully in there
application, what their experience was.

The answer I am looking for is:
What are some issues distributing an application across mulit platform and
operating systems?
Where can I find a tutorial , or other helpful samples, how to populate tree
and listviews?
what do I need to do to distribute the application?

any hints are very much appreciated.

Kind regards
Norman F
Nov 13 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Norman Fritag" <mu*****@ozemail.com.au> wrote in message
news:qt****************@nnrp1.ozemail.com.au...
Hi there

I have avoided to use active x controls because I thought they are causing
more problems then they are doing any good.
Yes, more problems then good is a reasonable answer!

.. About the only activeX control I used a lot was the calendar control.

However, activeX stuff does open you up to problems. I risked using the
calendar control because it IS part of the ms-access install IF YOU check
the box during installing to include the control.

For all other activeX controls, bets where off due to too many problems.

So, I did use the calendar control successfully for about 3 years for MANY
clients.; However, despite this, the calendar control caused me some support
calls (the target pc had access, but they had NOT included the calendar
control).

Worse, was I had a very good long time client that installed Business
Visions accounting software. It turns out their developers also used the
activeX calendar control. One day, they installed a new update to Business
visions, and my applications stopped working (well, the calendars did). What
happened is that the Business visions installed a newer version of the
calendar, and my stuff stopped working. (this by the way is the term VB
developers call dll hell....other programs break yours!!).

The temp solution was for me to bring in a floppy disk, and COPY OVER the
calendar (mscal.ocx). This had the *possible* risk of breaking BVsisons
(fortunately, it did not!). Further, every time a new VBsisons update came,
then my applications would break (Bvsions simply used a newer updated
version).

It was at this point I gave up on activeX (can't have support calls like
that). So, in less then 3 hours, I wrote my own calendar control (a sub
form) that looks just like the activeX one (in fact, I find it better
anyway). You can see some screen shots of it here:

http://www.attcanada.net/~kallal.msn/Atheme/index.htm

(the above screen shots are just to demo what the new access 2003 "themes"
screens look like (they make old access programs look very modern)
The answer I am looking for is:
What are some issues distributing an application across mulit platform and
operating systems?
The first problem is that you need to use a installer, as the target pc
might NOT have the control(s) installed. Further, you can't as a general
rule just "copy" the controls (this is both a legal issue, and also how
activeX controls work). So, in theory, you need a development platform (such
as VB, or developer edition of ms-access) that lets you "package" the
activeX controls with your software. Further, for a VERY long time (I think
going all the way back to windows 3.1) activeX controls have a built in
license system. That means if you installed Joes Graphics Drawing program,
you CAN NOT simply copy the acctiveX controls, and install them on another
pc (they will not work, you will get the "you don't have a license" message.
Thus, your users of your applications your distribute can't steal your
activeX controls).

So, you do need the developer edition of the activeX control(s) that LET YOU
distribute and setup the activeX control as part of a install package.

Since SO FEW ms-access developers don't use/distribute activeX programs with
ms-access, then the fact that the new access 2003 developer extensions DO
NOT now even install and setup activeX controls for you. If you been using
activeX controls and the developer tools for xp (2002), then the a2003
developer tools will be sort point on this issue. However, I really do like
the a2003 developer extensions, since they are now so simple, and as
mentioned, most of use don't use activeX controls with ms-access anyway.
Where can I find a tutorial , or other helpful samples, how to populate tree and listviews?
Here is a list of supported controls:

Supported ActiveX Controls for Microsoft Access 2000
http://support.microsoft.com/?id=208283

Custom ActiveX Control Features Supported in Access 2000
http://support.microsoft.com/?id=202104

Example Using TreeView Control Drag-and-Drop Capabilities
http://support.microsoft.com/?id=209898

ACC2000: How To Fill a TreeView Control Recursively
http://support.microsoft.com/?id=209891

ACC97: Microsoft Access 97 ActiveX Controls Sample Database Available in
Download Center
http://support.microsoft.com/?id=165437

(the above is real nice..but I don't know if there is a a2000 one).
what do I need to do to distribute the application?


You need some installer "system" to "ensure" that those controls get
installed and registered on the target pc (the a2002 developer (runtime)
royally free distribution system for ms-access will do this...but a2003 does
not do this for you anymore).
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.attcanada.net/~kallal.msn
Nov 13 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.