Hi.
Firstly a little information about me, I'll try not to ramble...
I have a little C+ text compiler experience, and some PLC ladder logic experience from college many years ago, but I've never used it since.
I also have a tiny amount of ASM experience, and the majority C programming experience both with microcontrollers, more recently in my second year of the degree I have just finished. And last week I began to delve into VB6. It seems I am doing things backwards maybe 😀 I completed one of those 21 day books in about a week. (It's a complex thing, but I've had a certain amount of code maintenance work added to my workload) VB I'm using a little in SCADA programming too.
So this week I started looking at VBA in excel, and as I'm still just starting,
My question is, what (if any) limitations does VBA have?
Can I create .exe as you can in VB6?
Any peculiarities?
I'm maintaining totally uncommented code in VB with default object names....so whilst I'm going thru it line by line and commenting so I understand whats happening in each function, well....
Whilst I'm at it, I may as well see if I can 'port' or recode (whatever the term would be) into a ExcelVBA version.
Is it possible to do this?
Edit:
Is it a waste of time? Or any reason to just stay with VB? Should I recode on Java instead?
Firstly a little information about me, I'll try not to ramble...
I have a little C+ text compiler experience, and some PLC ladder logic experience from college many years ago, but I've never used it since.
I also have a tiny amount of ASM experience, and the majority C programming experience both with microcontrollers, more recently in my second year of the degree I have just finished. And last week I began to delve into VB6. It seems I am doing things backwards maybe 😀 I completed one of those 21 day books in about a week. (It's a complex thing, but I've had a certain amount of code maintenance work added to my workload) VB I'm using a little in SCADA programming too.
So this week I started looking at VBA in excel, and as I'm still just starting,
My question is, what (if any) limitations does VBA have?
Can I create .exe as you can in VB6?
Any peculiarities?
I'm maintaining totally uncommented code in VB with default object names....so whilst I'm going thru it line by line and commenting so I understand whats happening in each function, well....
Whilst I'm at it, I may as well see if I can 'port' or recode (whatever the term would be) into a ExcelVBA version.
Is it possible to do this?
Edit:
Is it a waste of time? Or any reason to just stay with VB? Should I recode on Java instead?
Last edited:
About 20 years ago I wrote a couple thousand lines of VBA code.
I don't think the VBA code can be easily compiled into a stand-alone program, or a DLL - you must access it through one of the Microsoft Office products (Excel, Word, Access, etc). On the other hand, a VBA "macro" (as Microsoft insisted on calling the programs) can access the very sophisticated and powerful capabilities of the host Office application. In my prior incarnation, for example, I used VBA (started from WORD) to process, parse, and format a huge amount (100's of pages) of text data. The string processing capabilities of WORD - search-and-replace, cut-and-paste, count occurances, etc - were invaluable. Likewise in Excel, where VBA gives you access to the spreadsheet engine. If your VB program includes a lot of subroutines doing things that are similar to the native capabilities of WORD or Excel, the code may run faster or more reliably under VBA if those subroutines were replaced by calls directly to the appropriate WORD or Excel DLL's.
VBA also let you access many of the Windows system functions through their respective DLL's, though I don't think you could use the serial or parallel COM ports.
Dale
I don't think the VBA code can be easily compiled into a stand-alone program, or a DLL - you must access it through one of the Microsoft Office products (Excel, Word, Access, etc). On the other hand, a VBA "macro" (as Microsoft insisted on calling the programs) can access the very sophisticated and powerful capabilities of the host Office application. In my prior incarnation, for example, I used VBA (started from WORD) to process, parse, and format a huge amount (100's of pages) of text data. The string processing capabilities of WORD - search-and-replace, cut-and-paste, count occurances, etc - were invaluable. Likewise in Excel, where VBA gives you access to the spreadsheet engine. If your VB program includes a lot of subroutines doing things that are similar to the native capabilities of WORD or Excel, the code may run faster or more reliably under VBA if those subroutines were replaced by calls directly to the appropriate WORD or Excel DLL's.
VBA also let you access many of the Windows system functions through their respective DLL's, though I don't think you could use the serial or parallel COM ports.
Dale
Hi thanks for your answer
That's fairly similar to my situation.
I am taking data from a drive, processing it, and generating plots, tabulated pages, and performing some calculation. Almost purely report generation, with some mathematics thrown in, using data from txt file
In my case, the COM would be handy ( another piece of software I am maintaining does use Ethernet) so it looks like I can only do so much 😀
That's fairly similar to my situation.
I am taking data from a drive, processing it, and generating plots, tabulated pages, and performing some calculation. Almost purely report generation, with some mathematics thrown in, using data from txt file
In my case, the COM would be handy ( another piece of software I am maintaining does use Ethernet) so it looks like I can only do so much 😀
- Status
- Not open for further replies.