On Wed, 17 Aug 2011 15:35:00 +0200, The Frog
<mr.frog.to.you (AT) googlemail (DOT) com> wrote:

I've read a number of comments which state that things in VB.Net are
just close enough to cause you problems. For example the definition
of Integer. It's better to go to C# so they don't trip you up.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

On Aug 17, 3:52*pm, "David-W-Fenton" <NoEm... (AT) SeeSignature (DOT) invalid>
wrote:
We could get the Ribbon in earlier versions of Access :-) :-).
Besides Workflows, how about:

"Geneva" style Security
Multi-tier
MVVM pattern (Access is weak when it comes to stacking dynamic
subforms)
Multithreading
Client Multicore
Accessing GPU's
Adding Touch capability
Integrating sensor data
UML data programming
Sync Framework
Easy hookup to web services
Automation/testing for controls
Not having to wait for MS to trickle down future features

Web:

Extensible cache
OData data access
Azure (for those so inclined)
WPF controls
WCF options
jQuery integration

In addition to the capabilities offered by integration with .NET,
Visual Studio has a very exciting new feature - with minimal program
overhead, a user can send a bug report and the developer can go right
to the bug and see the state of all the variables. Plus, from there
they can go backwards or forwards to see each step from the
'recording'. I don't get many bug reports, but when I do I don't want
to tell the user that I was unable to duplicate the circumstances that
led to the bug. That would be a great new feature for Access.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com

On Aug 18, 10:35*pm, "James A. Fortune" <CDMAPos... (AT) FortuneJames (DOT) com>
wrote:

I forgot an important one (maybe more also):

Entity Framework (EF)

Larger Access projects tend toward queries having lots of joins.
Those complex SQL queries slow down development. EF simplifies the
process by having SQL "shortcuts" to different join combinations,
thereby simplifying the queries.

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com

The Frog <mr.frog.to.you (AT) googlemail (DOT) com> wrote in
news:j2j4bu$jmn$1 (AT) speranza (DOT) aioe.org:

I can't see how .NET can *extend* Access in this way. Surely the
threading issue is a characteristic of Access and not of VBA?

But again, if you're extending Access with .NET, aren't you going to
continue to bump up against the limitations of Access? It seems to
me that you could only get the significant benefits of .NET you
adduce (the ones I haven't quoted I consider to not be important) if
..NET were able to completely replace VBA as the programming
environment for Access. I just can't see that happening without a
major rewrite of Access.

And I fear that what would happen in that case is that the new
beefed-up macros would be kept and .NET would be added and VBA would
be entirely dropped. This would be a really bad thing, in my
opinion.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

Replying to several of the above threads in one here:

David, I understand your concerns regarding the removal of VBA, and that
would be a travesty to do IMO. The limitations of Access are the same as
those in Excel, Word, PowerPoint, and Outlook. This leads me to believe
that the limitations are based around the implementation of VBA into
those applications. Not having access to the source code for VBA or any
of the afore mentioned applications I cannot say for sure. The hope with
adding .Net to Access, at least for me, is to sidestep some of those
limitations by 'pushing' some of the heavy lifting (so to speak) for
tasks that VBA does not do so well into an environment where they can be
handled better. The limitations that might be imposed by Access on that
are something I dont know how to calculate. The alternative is to not
enhance Access at all and search for another approach to solving these
problems. I would prefer to be able to stay with Access. I find it a
great tool, so much so that it has convinced a complete sceptic into a
becoming an ardent supporter. Now when I look at creating solutions
inside SME's and departments I think of Access first, rather than an
option of last resort. IMO it is a great product that would only be made
better by the inclusion of native, integrated access with the .Net
framework.

As for the language to be used inside of this theoretical version of
Access I would be comfortable with either C# (being quite similar
syntactically to Java), or VB.Net. The point about data types is a very
good one. There would probably have to be some clear distinctions
between the VBA versions of things and the .Net versions. Arrays leap to
mind here too. Still, declaring data types is all part of the fun and games.

The more I think about it the more things come to mind that Access could
benefit from being able to use .Net natively. James has listed many
possibilities, and I am sure that there are many more if we bother to
think about it further. Crypto is one that is forefront in my mind -
sure VBA can do it, but I find the encapsulation better in .Net (and the
approach in general, it just seems 'cleaner'). I was also thinking that
it would be great to be able to 'suck in' an already compiled class in
CLR (doesnt really matter what language it was written in then), and be
able to use that like a VBA class module. Just another thought.

--
Cheers

The Frog

On Sat, 20 Aug 2011 16:08:23 +0200, The Frog
<mr.frog.to.you (AT) googlemail (DOT) com> wrote:

I would assume that all .Net languages would work given CLR.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

Does anyone think that this will be thought about by MS at any stage?
Does MS have a place to lodge suggestions like this that they actually
read / listen to?
--
Cheers

The Frog

On Wed, 24 Aug 2011 18:08:50 +0200, The Frog
<mr.frog.to.you (AT) googlemail (DOT) com> wrote:

No idea. NDA or otherwise. However I think the Office team knows
that removing VBA will cause just a little moaning and gnashing.
But will they add .Net? No idea.

Err, there are times when they don't seem to listen much to MVPs or
folks who attend their Insiders sessions, now called developer
kitchens.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

On Wed, 24 Aug 2011 21:08:43 -0600, Tony Toews
<ttoews (AT) telusplanet (DOT) net> wrote:

BTW note that Mac Office removed VBA and has now put it back in.
Neither decision was taken lightly. And there were significant
architecture reasons to taking it out IIRC as it would've been a lot
of work to get it going when Apple switched to using Intel processors.
But the Mac Office team decided to put VBA back in.

Toy
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/