Forms and modules in VBA to be converted to C#
Hi
I'm starting to convert a number of "utilitarian apps" from Access/VBA to C#, and some of the equivalents escape me sofar.
By "utiltarian" I mean Access apps that run unattended, process data in various databases (mostly in one SQL Server DB), and possibly go through various phases of processing. So I have typically constructed them around one main form which when loaded calls a number of routines, some located in the form itself, and many located in modules, of which there are 2 categories: standard, generic modules which are used by many of the apps, and specific modules which do some specific processing only in one of the apps.
Many of my modules log what they are doing in a table in SQL Server, and they also add the same or similar kind of text log entries in one listbox on the main form, which always bear the same name, lbProgress, in all apps and which allows me when developing and testing to see what the code is doing and what problems it encounters. So basically I have this:
- main form calls subroutine A in module X by passing any needed arguments, but always Me as argument
- subroutine A (which has the argument "frm as Form" to map the Me argument in the sub call in the main form) starts working and, when it wants to "publish" the fact that it has reached some step in the processing, it calls a generic logging routine, passing it its own "frm" parameter and the text to log as arguments
- the generic logging routine uses these arguments to add the logging text to the main form's list box lbProgress by referring to it as frm.lbProgress
So in pseudo code, it is something like (simplified):
Private Sub Form_Load() (of frmMain form)
...
Call A(Me)
...
End Sub
in specific module of app:
public Sub A(frm as Form)
...
' Want to log text "Step 1 completed"
call LogProgress(frm, "Step 1 completed")
...
End Sub
In generic module modAppLogging:
Public Sub LogProgress(frm as Form, sLogText as String)
Dim Temp as Variant
....
Temp = SysCmd(acSysCmdSetStatus, sLogText )
frm.lbProgress.AddItem sLogtext
...
End Sub
I thought I would therefore start to rewrite such a generic module, which is basically a collection of public sub's doing some processing which may or may not access data in tables in a SQL Server DB, and to make a solution with one form as project and the generic module code in a sealed class. However, I'm stumbling on many small obstacles:
- the main form passes its reference "Me" in the sub call to A, because it might be used by A and by the LogProgress generic routine. What's the equivalent to "Me" in C# ? "this" ?
- is there an equivalent in C# for the SysCmd call, which just shows the log text in the status bar of the form ?
- the LogProgress routine uses in VBA the 2 arguments shown above: a reference to the main form, and a string. I can't fathom what type this "frm" variable should be in the sealed class A and in the sealed class where LogProgress is, i.e what's the type in:
public static void LogProgress( ??Type?? frm, string sLogText)
Thanks for helping me with these probably trivial problems.
Bernard
I'm starting to convert a number of "utilitarian apps" from Access/VBA to C#, and some of the equivalents escape me sofar.
By "utiltarian" I mean Access apps that run unattended, process data in various databases (mostly in one SQL Server DB), and possibly go through various phases of processing. So I have typically constructed them around one main form which when loaded calls a number of routines, some located in the form itself, and many located in modules, of which there are 2 categories: standard, generic modules which are used by many of the apps, and specific modules which do some specific processing only in one of the apps.
Many of my modules log what they are doing in a table in SQL Server, and they also add the same or similar kind of text log entries in one listbox on the main form, which always bear the same name, lbProgress, in all apps and which allows me when developing and testing to see what the code is doing and what problems it encounters. So basically I have this:
- main form calls subroutine A in module X by passing any needed arguments, but always Me as argument
- subroutine A (which has the argument "frm as Form" to map the Me argument in the sub call in the main form) starts working and, when it wants to "publish" the fact that it has reached some step in the processing, it calls a generic logging routine, passing it its own "frm" parameter and the text to log as arguments
- the generic logging routine uses these arguments to add the logging text to the main form's list box lbProgress by referring to it as frm.lbProgress
So in pseudo code, it is something like (simplified):
Private Sub Form_Load() (of frmMain form)
...
Call A(Me)
...
End Sub
in specific module of app:
public Sub A(frm as Form)
...
' Want to log text "Step 1 completed"
call LogProgress(frm, "Step 1 completed")
...
End Sub
In generic module modAppLogging:
Public Sub LogProgress(frm as Form, sLogText as String)
Dim Temp as Variant
....
Temp = SysCmd(acSysCmdSetStatus, sLogText )
frm.lbProgress.AddItem sLogtext
...
End Sub
I thought I would therefore start to rewrite such a generic module, which is basically a collection of public sub's doing some processing which may or may not access data in tables in a SQL Server DB, and to make a solution with one form as project and the generic module code in a sealed class. However, I'm stumbling on many small obstacles:
- the main form passes its reference "Me" in the sub call to A, because it might be used by A and by the LogProgress generic routine. What's the equivalent to "Me" in C# ? "this" ?
- is there an equivalent in C# for the SysCmd call, which just shows the log text in the status bar of the form ?
- the LogProgress routine uses in VBA the 2 arguments shown above: a reference to the main form, and a string. I can't fathom what type this "frm" variable should be in the sealed class A and in the sealed class where LogProgress is, i.e what's the type in:
public static void LogProgress( ??Type?? frm, string sLogText)
Thanks for helping me with these probably trivial problems.
Bernard
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
kaufmed has much more experience in this, so I'd certainly defer to his judgement in this matter. My goal with the post was to try and pave something of a path from VBA to .NET (if such a thing exists, that is).
ASKER
Hi Scott
Yes, I know that such apps do not need a UI, but because they do sometimes complicated stuff, it's much nicer to follow what's happening in one single app on a form listbox being filled by the executing code than fishing with SQL queries in a huge table with logging entries from 10 different apps.
And yes I know I'm (unnecessarily) trying to mimic what happens in my Access apps, but I thought that would teach me at the same time a number of things which I'd need anyway later on, because I will have to convert also typical data manipulation apps used by people. And users would anyway not be able to (mis)use my service-type of apps, because they will run on servers on which they' have no access. All they'll ever see is the interactive apps they have today, just in another guise (Win Forms or web forms with ASP.Net).
I HAVE to use C#, I would have preferred VB 10 times over, but that was not for me to decide.
OK, thanks for your valuable inputs, I'll see how much and how fast I can "bend" my Access habits into C#-conform habits :-)
Yes, I know that such apps do not need a UI, but because they do sometimes complicated stuff, it's much nicer to follow what's happening in one single app on a form listbox being filled by the executing code than fishing with SQL queries in a huge table with logging entries from 10 different apps.
And yes I know I'm (unnecessarily) trying to mimic what happens in my Access apps, but I thought that would teach me at the same time a number of things which I'd need anyway later on, because I will have to convert also typical data manipulation apps used by people. And users would anyway not be able to (mis)use my service-type of apps, because they will run on servers on which they' have no access. All they'll ever see is the interactive apps they have today, just in another guise (Win Forms or web forms with ASP.Net).
I HAVE to use C#, I would have preferred VB 10 times over, but that was not for me to decide.
OK, thanks for your valuable inputs, I'll see how much and how fast I can "bend" my Access habits into C#-conform habits :-)
All they'll ever see is the interactive apps they have today, just in another guise (Win Forms or web forms with ASP.Net).You'll want to take an n-tiered approach to your development then. With such an approach, you will be able to easily swap out layers as you see fit. For example, if you made 3 tiers--a UI layer, a service (validation) layer, and a data layer--you could easily swap out the UI layer between WinForms and WebForms (or something else)--the only thing changing is the technology that is used to display the data.
ASKER
Hi kaufmed
Yep, that sounds good, and I'll do it in the end. My problem is that I have very little time to do the conversion (about a year to convert 30,000 lines of VBA code + forms, queries and a few reports) spread over 20+ Access apps, so maybe I'll do it 2-tier first to gain basic experience, and then improve afterwards when I get to the maintenance mode period. I know, it's nearly double work, but I hardly have any choice and too little know how to risk grand plans and perfect structures. The whole thing has been kicked off by guys making lots of politics, so there are loads of aspects which I have to consider which hamper a healthy development. And being a lone-ranger contractor, I cannot impose my views against IT departments with thousands of employees.
Yep, that sounds good, and I'll do it in the end. My problem is that I have very little time to do the conversion (about a year to convert 30,000 lines of VBA code + forms, queries and a few reports) spread over 20+ Access apps, so maybe I'll do it 2-tier first to gain basic experience, and then improve afterwards when I get to the maintenance mode period. I know, it's nearly double work, but I hardly have any choice and too little know how to risk grand plans and perfect structures. The whole thing has been kicked off by guys making lots of politics, so there are loads of aspects which I have to consider which hamper a healthy development. And being a lone-ranger contractor, I cannot impose my views against IT departments with thousands of employees.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yes.
I disagree with this. Creating globals is the old way of thinking. The preferred way is to pass around abstractions of your form by way of interfaces and abstract classes. But I won't subject you to that at this point in your learning = )