 | |
#11
 
| |||
| |||
|
Re: Friend in classes -
04-18-2011
, 04:49 PM
|
Hi David, I was not aware that A2010 had the potential for .Net integration. You could probably make some nice add-ins with .Net and also probably cannabalise a lot of the solutions / code available on the net for saolving various odds-n-sods. My interest in .Net integration is OO related. With regards to VBA vs VB I am not so much comparing the languages as the IDE's. The VBA IDE IMO is missing a few things that would be quite helpful, such as being able to set class attributes, hide procedures / properties that dont need to be shown and so on. Nothing major, just a few tweaks. Being able to have multiple VBA projects in a single 'Office Document' (such as an MDB file) would be useful to me too. I do the import export thing at the moment to set attributes, but hiding the default enumerator on a collection class is just not possible (VBA quietly ignores the attribute setting). I was mucking about with a few friends on the weekend and one of them had an interesting suggestion. Create a 'standard' application that is fixed in its functionality - it simply acts as a framework. Deploy this to as many people as you wish - it is valueless by itself. To distribute your application you ship a library database with all the forms, reports, etc... which the FE knows how to read and use. The FE could then in theory use as many libraries as is needed to produce a completely 'modular' application. I said that it is an interesting idea but that it is probably better to do something like that with another tool instead of Access. IMO you would really need a full OO environment to handle something like that, but perhaps I am wrong. Its a moot point I suppose as the VBA IDE would make developing something like that hell. Cheers The Frog |
I have a standard "Utilities" database that has a treeview type menu system
together with everything to set it up. Also includes such things as Company
information (holda paths to all sorts of files and things like letterhead
addresses, Backup routine, magnifying glass, mail merge routines, complex
formfitering etc. No tables, all data supplied from the FE database (via
links to the BE database). Just set a reference to Utilities.AccDb in the
reference section and use the AutoExec macro to set up the reference. There
is also a reference in the FE Db to "ShrinkerStretcher" from Petere's
software which acts in the same way to shrink / stretch forms & all their
controls Phil
Phil
Phil
#12
| |||
| |||
|
|
I was not aware that A2010 had the potential for .Net integration. |
suggested.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#13
| |||
| |||
|
|
Frankly, I don't see any benefit at all in integrating .NET into a COM-based environment. What do you accomplish, except to demote the capabilities of .NET to be no greater than those of VBA itself? |
integrating .NET into Access:
http://groups.google.com/group/micro...c3aa54d31ea188
I'm in no hurry to get rid of VBA, but .NET - with or without VBA -
brings a lot to the table (no pun intended). Perhaps I didn't
understand exactly what you meant. For me, bringing .NET capability
to Access (versions since 97) quickens my pulse. I just read some
interesting bits in:
Chapter 6: Integrating Legacy Code with C#
from:
C# Developer's Headstart
M. Michaelis, P. Spokas
McGraw-Hill, 2001
ISBN 0-07-219116-3
I'm hoping to teach Access some new tricks.
James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.