Is there rather painless way to convert old VB6 or Access 2000 VBA code to C# or VB.NET?
Any tutorials on the topic?
Printable View
Is there rather painless way to convert old VB6 or Access 2000 VBA code to C# or VB.NET?
Any tutorials on the topic?
For VB6... no.
For Access2000-VBA... why not import that into a more recent version of Access?
(it's still a fully supported MS-product)...
Olaf
Yes we have new Access, 365 or that version 16, whatever.
Is it painless to import old Access code to new? Have somebody tried it?
I'm not an "Access-Guy" - perhaps a direct conversion-attempt (right from 2000 to 365) -Quote:
Originally Posted by kutlesh
is a "too large step to take".
If that's the case (why not simply try it?) - then an intermediate import into an "in-between" Access-version might help...
There's a few Access-experts here who will probably soon chime in...
(if not, asking that question in the Office-section of this Forum will probably help).
Olaf
Newer Access use C# and VB.NET or do they use VBA?
Yeess, we have lot of legacy code, made in VBA and Access 2000. Yes its easy to say, never use Access...
Older versions of VS had a converter included that would convert VB6 to VB.Net. It was far from perfect but did work to some degree. The last version that included it was VS2008.
https://answers.microsoft.com/en-us/...a-fee61eadb901Quote:
Originally Posted by Eduardo-
Olaf
Yes, I've done this many times through the years. There was once talk coming from Microsoft that they were going to upgrade the VBA to .NET, but nothing ever materialized. Therefore, basically, all of the VBA is still VB6 (i.e., COM architecture based).Quote:
Originally Posted by kutlesh
I have VBA code in both Excel and Access that has migrated through every version of MS-Office. Occasionally there are some strange glitches, but never anything major. And, these glitches always have to do with small changes in the way properties and/or methods of Excel or Access objects work, and don't have anything to do with the core VBA language.
Regarding the core VBA languages (excluding Excel and/or Access specific objects and members), I know of no differences between VBA and VB6, other than the explicit presence of the LongLong type, the LongPtr type, the PtrSafe API declaration directive, and the ability to run in a 64-bit environment.
I suppose a couple of other differences are (in the VBA) the lack of User Controls, and the intrinsic controls are a bit different. Still, the core language is virtually identical to VB6.
Good Luck,
Elroy
I misunderstood the question, I thought he wanted to convert VBA to .NET for code inside Access.Quote:
Originally Posted by Schmidt
He has stated two different questions: 1) porting VB6 or VBA to C# or VB.NET, and 2) migrating VBA to newer versions of MS-Office. I've got no idea which is the primary question for Kutlesh.Quote:
Originally Posted by Eduardo-
I was a Qualified chartered Accountant, and then a Senior Analyst in IT in a Large bank, and the 2nd largest Telecommunications company in the world, for 20 years.
I am retired now, but used to shudder at the amount of processing that was done in Excel spreadsheets.
I still shudder when I think about it.
But now I am also glad that it all exists, because MS cannot abandon VBA like it did with VB6 (and possibly is attempting with VB.NET ?)
Rob
Often wondered about that...Quote:
Originally Posted by Bobbles
Yes I mixed two questions. Probably more appropriate is to upgrade old Access 2000 apps to the new Access 16.
EDIT:
Hmm, why I bother so much. Just upgrade the old apps in new Access.
I asked this question because a thought crossed my mind. If you have ton of VBA code in Access 2000, what would you do to rework it in other newer and more powerful technology... Access is not very attractive.
No new young programmers would like to work in Access VBA, sadly :) :(
There is a bit of nuance to this question you're asking. You can't think in terms of converting VBA to C#/VB.Net. You see, VBA is more than just a language. It's an entire environment designed to help automate tasks within the Office Suit of products like Word. VBA is used within Access and as far as I know, it has no bindings to .Net. In this case there is no need to translate anything.Quote:
Originally Posted by kutlesh
However, Microsoft Office exports COM objects that allow you to control various thinks like Word documents and Excel spreadsheets from external applications. In this case, you question makes a lot more sense. You could write an application in C# that use these COM objects to interact with Office. You could have VB6 code that does the same thing that could be translated to VB.Net.
TLDR;
VBA is internal to Office and is based on COM. You can only use what Office allows you to use. If it doesn't allow you to use the .Net Framework or .Net Core then the question is moot. You stick with VBA.
One note about PtrSafe keyword... If converting 32bit to 64bit VBA, then I don't find that truly painless - has a learning curve. In addition, some UDT/Type declarations may need to be changed to reference 64bit members vs 32bit members. This is more of an issue if needing to do pointer math, calculating offsets from VarPtrs. Maybe there is a reliable site that has APIs and UDTs defined with PtrSafe 64bit declarations?
visual basic code to java(b4a make app tool)。
basic code to code(freebasic),Everything is possible. Many softwares do a very good job in this regard. The key is that they cannot be fully compatible, but they can be very convenient for some common applications. Very powerful.
freebasic software,have x32,x64 api,type declared
I use freebasic.exe to write special functions for loading and running dlls in memory. It took a lot of time to convert a 32-bit program to 64-bit, but the data structure has changed. There are still many places to pay attention to. This does cost a lot of money. Please ignore the following Chinese
我曾经使用 freebasic 编写内存加载运行dll的特殊功能，32位程序转换到64位的时候花了大量时间，只是数据结构发生了变化，还有很多地方也要注意，这个确实要不少成本。