Third Party Controls (Yay or Nay)???

[Pyro]

Just curious to know if many developers are using third party controls in their applications?

Personally in 8 years of developing Access databases, I have only ever used one non-native control. Generally I try to steer clear of them as (in my limited experience) i find front end deployment painful. Not to mention many of them seem cost prohibitive.

If you have a good reason for or against, i would love to hear it too.

 

[pbaldy]

I also steer clear. The only one that comes to mind is an ActiveX control for a signature pad. Weird things happen if the app is run without that installed, things not related to capturing a signature.

 

[MarlaC]

I don't use any third-party controls (although I did use an ActiveX calendar control before that was made part of Access), but I do use a tool add-in, MZ-Tools. I have found it very valuable, especially with inserting my custom error handler.

 

[pbaldy]

MZ Tools and Smart Indenter are almost must-haves for serious developers. I wouldn't call them controls though.

 

[MarlaC]

Agreed. That's why I clarified "tool add-in", as it's definitely not a control.

 

[HiTechCoach]

YES! Absolutely...

I can from the VB application development to Access.

Since 1995 I have been using custom controls and code libraries, like a DLL for zipping with Access. . I use both third-party controls and owns I create.

Why, you ask? Access does the basics well. Access is a good basic foundation for buit-in solutions. Unfortunately it does not do everything I need for almost every solution I create to mass market. If it did, Access it would cost a whole lot more.

A little History of Microsoft Development Platforms:

VB did the basics for all applications. NOT everything for every application. This is true today with Visual Studios. If you are creating games you have different needs that if you are creating an database application like an accounting system. To meet your needs you can create you own custom controls or purchase third-party controls and code libraries.

Microsoft has always done a great job of providing the basics. They do not try to create everything for developers. Microsoft has always been very supported of developers to create custom controls to extend the power of their development platforms.

You can make Access better without waiting on Microsoft

Microsoft has not been doing much to increase the power of the Access desktop database since the 2003 versions. Almost improvement has been for Web databases/apps.


What can we do? Use custom controls!

With the use of custom controls you can extend the power of Access to meet your needs.

For some reason the Access community has been very resistant to using custom controls and installer packages. Even Access itself requires an installer. Almost every application on your desktop PC requires an installer with the exception of portal apps.

The resistance to using custom controls by the Access community has probably influenced Microsoft to not make this better like they have for Word and Excel.

You can create your own custom controls or use third-party controls form others.

Access gets a bad reputation with application developers as not a true development platform. When I ask why, I commonly hear that there is no third-party custom control support. The good news is that many controls for VB will work with VBA.


Deployment

With VB applications and many other development platforms, it is common to use an installer to deploy the applications to be sure that all the controls get installed.


When I create an Access based solution for mass deployment to customers I create an installed package. It will install the Access runtime if needed. I have been dong this for may years.


How to Deploy without an installer

One trick is to use custom controls that do not have to be registered.

I actually store the DLLs in my front end. When the front end opens is extracts the files.

I have created an example that uses a barcode font that is stored in the database.

Print Barcodes on an Access report (Click Here)

This example is in Access 2000 format. It should work fine with Access 2000 and later.

This example Access database shows how to print the Barcode 39 (also called 3 of 9) on an Access Report.

**Note: The barcode font is stored in a table as a BLOB. It is installed and removed automatically for you.

 

[speakers_86]

Does this work with mde?

 

[HiTechCoach]

Does this work with mde?

If you are referring to my auto deployment (using BLOBs) then yes. I have several applications in mde and accde/accdr format using it now.

FWIW: I run every deployed front end compiled (mde/accde) with the Access Runtime or the full version forced into Runtime mode.

NOTE: The example I posted has the code to extract a font and also register it. It is code I got from an example posted on another site. I have written my own code that I use in my applications. It does a lot more. For example, it can register an OCX or DLL if needed.

 

[speakers_86]

My only experience with this was in trying to use the ActiveX treeview control. Deployment was impossible due to the common controls reference being installed at different paths. Can this technique be a solution?

 

[speakers_86]

Also what about iTextSharp, the PDF library? Will this technique work for that too?

 

[HiTechCoach]

Also what about iTextSharp, the PDF library? Will this technique work for that too?

Again I assume you are asking about the auto/self deployment method where the files are stored int he database.

I have not use the iTextSharp control. Checked it out. Looks very interesting. It will require the .NET framework to be installed. If you do not use an installer, you will have to figure out some way get the .NET framework installed if needed.

My preferred method of deployment is to create an installer package.

Back in with Windows 3.x/95 days I used VB code to create installers. Since I have used commercial software.

I was curious just how much I could do with VBA to make a database self deploying.

I was able to create a self deploying database that used third-party libraries and fonts. The caveat is that it works best with libraries that do not require it to be registered with windows. I have had the idea for creating a code library for installing controls that could be include in the front end. It would be something that I would sell to Access developers. If I thought there was enough demand, I would do it. Just not sure.