Mwp.Reid at Queens-Belfast.AC.UK
Mwp.Reid at Queens-Belfast.AC.UK
Tue Feb 4 12:03:00 CST 2003
I do knoe MS have made a plug in available that check VB code for .NET. You can build in rules etc to make your VB stuff portable to .NET in the future. Martin Quoting Shamil Salakhetdinov <shamil at smsconsulting.spb.ru>: > > And will we get true OO with inheritance etc? That would make it > all > > worthwhile. > Yes, we will get it within VB.NET and C# and J# and other OO > languages/development tools supporting .NET framework like DELPHI etc. > IMO there will be never true inheritance within VBA - what for? when > there > is already VB.NET and C#? > > > And will it break all my existing apps that use the built in VBA? > That > > would make it a disaster. > No, I don't think it will break all(any) of your existing apps "one > dark > day" - they promise to support VBA from within VS.NET IDE - I guess > VBA > will become dead(frozen) language like Latin but they will support > (translate it into executables) for a while but then inevitably but > gradually(within several years) we will be forced to move to VB.NET > using > the feature of (almost) automatic conversion of VBA code to VB.NET code > or > even to C#... Is that good or bad? - good because this promise to not > let us > to be idle using legacy VBA code - we will have a lot of work of > conversion > VBA->VB.NET... It's not that good for customers because this > additiional > work means additional spendings for them... > > May it happen they will support VBA forever from within VS.NET IDE? - > it > seems to be possible scenario too - after all .NET framework is a huge > set > of classes and I don't see any problems (except time and money needed > for > developement) to make them available in VBA like(/a' la) COM objects - > in > fact even now it's possible to write wrapper/helper VB.NET/C# dlls > available > in VBA and exposing custom or .NET classes' interfaces if needed (an > they > will look similar to COM objects with late(IDispatch) or late/early > (dual) > program interfaces). Maybe something like that exists already but I > didn't > see it yet - anybody?... > > Again, these are guesses only, nothing more... > > Shamil > > ----- Original Message ----- > From: "John W. Colby" <jcolby at colbyconsulting.com> > To: <accessd at databaseadvisors.com> > Sent: Tuesday, February 04, 2003 7:46 PM > Subject: RE: [AccessD] .net > > > > And will we get true OO with inheritance etc? That would make it > all > > worthwhile. > > > > And will it break all my existing apps that use the built in VBA? > That > > would make it a disaster. > > > > John W. Colby > > Colby Consulting > > www.ColbyConsulting.com > > > > -----Original Message----- > > From: accessd-admin at databaseadvisors.com > > [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Shamil > > Salakhetdinov > > Sent: Tuesday, February 04, 2003 11:09 AM > > To: accessd at databaseadvisors.com > > Subject: Re: [AccessD] .net > > > > > > AFAIU MS Access/Word/Excel VBA programming from within MS > Access/Word/Excel > > IDEs seems to be already marked as "must die" at MS: > > > > http://msdn.microsoft.com/vstudio/productinfo/roadmap.asp > > > > This should happen with arrival of .NET Framework 2.0 and VS.NET for > Yukon > > in 2004 and Office12 or later?... > > > > <<< > > Office programmability. The tools and components within Microsoft > Office® > > are widely used as a foundation for smart client application > development, > > and "Visual Studio for Yukon" will seek to unify the programming > experience > > between Visual Studio .NET and Office. "Visual Studio for Yukon" > will > > deliver support in the Visual Studio IDE for Office development, > while > > simultaneously continuing support for the popular VBA development > approach. > > With "Visual Studio for Yukon" the full breadth of Microsoft Office > will > be > > available for the first time to developers using Visual Studio .NET. > > >>> > > > > IMO it looks like they at MS plan to remove ALT+F11(VBA programming > support) > > from MS Access/Word/Excel IDEs completely moving it to VS .NET. Are > these > > good or bad news? IMO their approach to unify .NET and VBA > progamming > > under/within VS.NET is a right step forward. And with arrival of > such > > architecure MS Word/MS Excel macro viruses' problem will be solved > > automagically... > > > > Of course I can be (completely) wrong with my guessing based on the > roadmap > > info referred above. > > We will live, we will see... > > > > Shamil > > > > > > ----- Original Message ----- > > From: "Martin Reid" <mwp.reid at queens-belfast.ac.uk> > > To: <accessd at databaseadvisors.com> > > Sent: Tuesday, February 04, 2003 6:33 PM > > Subject: Re: [AccessD] .net > > > > > > > I think the true future of Access will not be really known > > > until Access 12 is available. I do know JET and DAO are > > > dead today. No further development of either AFAIK. Could > > > all change but we have to wait and see. > > > > > > Lot of confusion it would appear > > > > > > Martin > > > > > > Martin WP Reid > > > Information Services > > > Queens University Belfast > > > > > > Tel: (02890) 273750 > > > > > > > > > ---------------------- > > > > > > > > > _______________________________________________ > > > AccessD mailing list > > > AccessD at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/accessd > > > Website: http://www.databaseadvisors.com > > > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > > > > > > > _______________________________________________ > > AccessD mailing list > > AccessD at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/accessd > > Website: http://www.databaseadvisors.com > > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >