[Gambas-user] Correct strategy for VB static var conversion to Gambas?
johna at starflightinc.com
Sun May 30 03:00:55 CEST 2021
On 5/29/2021 1:09 PM, Benoît Minisini wrote:
> Le 29/05/2021 à 21:25, John Anderson a écrit :
>> On converting larger codebase from VB6 to Gambas, I wanted to double
>> check my method for converting "static" type variable module declares
>> into the Gambas way. This might be obvious to everyone, but I just
>> wanted to be sure. Or am I smoking the wrong stuff again?
> I didn't allow to declare static class variable inside functions, like
> you can do in C (and other languages).
> I think it's mainly for the same reason I prevented declaring local
> variables anywhere in the code.
> After some pressure from people I won't give the names, I accepted to
> allow local variable declaration anywhere.
> Now I regret. It makes the code so ugly for me! :-)
> So maybe I could allow declaring "static variables" (actually private
> global class variables) inside functions in the future.
> In the meantime, you have to use the wokraround you described.
> Something like that:
> Public Sub MyFunction()
> Private (or 'Static' or something else?) somevar As String = "first"
> Static Private MyFunction_somevar As String = "first"
> Public Sub MyFunction()
> One question remains: does the "static" 'somevar' be actually static
> or not? I.e. is there only one 'somevar' variable for all the process,
> or one 'somevar' variable for each object of the class. How to make
> the difference?
>> 'Gambas module file
>> 'Static-like vars declared here
>> Private myLVar As Long = 0
>> Private myArray[20, 500] As Integer
> One remark about that last line: don't do that.
> Don't use the syntax myArray[20, 500], because it creates an embedded
> array which is a special beast that is mainly useful for interfacing
> with C code.
> Use a "normal" array instead (which is a standard Gambas object):
> Private myArray As New Integer[20, 500]
Well here's the thing...We don't care much about Gambas-type objects on
this project, because 95% of what we're doing IS working directly with
C-Code. So if an object is not C-friendly, it has no use for us. We
don't care what the source code looks like, as long as it works exactly
the same way the VB6 code has been running since 1998 (i.e. millions of
machine hours testing, running 24/7) - and what you've done with Gambas
is a really good superVB, Benoît !! Love that J-I-T stuff for the
elaborate code-math sections!! That also works good on some XML
configuration files we have to read in. Neat! That is a HUGE upgrade
for us right there.
Right now, my Sorta-Kinda-Automated VB6 to Gambas Converted Build helper
is being tested to work like this - Because I ain't manually converting
84,000 lines of code from VB6 to Gambas when -MOST EVERYTHING- can stay
the same...Obviously ON ERROR sections will have to get tweaked, but
doing the following can automate a lot of conversion from VB world and
bridge to Gambas:
This is VERY rough FIRST DRAFT I'm testing on some smaller projects -
having a way to declare a variable as type static would really help a
lot for doing VB6 to Gambas conversion - but it is not entirely
required. Just more work if we don't have it:
1. First we scan the entire VB6 project files and look for global vars
and move those declares into Gambas module "Globals.mod". Yes we have a
lot of them and No I won't get into a religious argument as to why they
are there. This is a GUI for a semiconductor fab machine on an assembly
line, and you learn in a hurry why you sometimes need global vars when
you have to work fast with C-code threads for coordinating machine
motors controls, machine vision, and handling operator command inputs,
configuration setups, spewing out performance reports and test data for
the next machine on the assembly line. "This is where theory ends and
reality begins", as the sign on my lab says. If you can keep the system
design so all you do is pass a data struct memory pointer form one piece
of code to the next, you're good. And no weird ways of storing
variables...Large Structs and arrays of Structs all have to pass back
and forth to C without any extra conversion steps. Passing single
pointer should do it in most cases.
1A: For every variable that was put into Globals.mod, we have go back
through all source code and replace every instance of myglobalvar with
Globals.myglobalvar. As per Gambas instructions.
IDEA>>> This would be cool: Somewhere at top of Globals.mod, you have
something like #Pragma SET_DEFAULT_MODULE TRUE Or use whatever keyword
or environment variable you like. This tells Gambas to search this
"Default Module" for any unknown objects it can't find a reference to
in the rest of the project. Now I don't have to go thru code updating
all the myglobalvar names to Globals.myglobalvar - If Gambas comes to a
var object name it doesn't know, it will just go look in the Default
ModuleName to check there. In other words give the system a "path" to
look for object declares.
2. Now we go thru VB6 sources and change all "Double" type declares to
"Float". Really ?? Is there any way we can get Double type defined as
the same as Float type? It looks like keyword is available according to
docs, and that would make it easier for us VB / C guys to avoid
mistakes. But whatever.
3. Now I have to go thru all the VB6 modules and pull out every Sub /
Function of name myFuncName or mySubName. Build a new Gambas.mod file
of name myFuncName or mySubName, and paste existing VB6 code just for
the that -one- procedure into the .mod file.
NOTE: Each new Gambas Mod file will have only one converted
Sub/Function from VB6 code.
4. In the new Mod file, look for any static vars, and place those at
the top, outside of the procedure call, as Private Static. Or just
Private, not sure if you also need to use Static also in a module
5. In the new Mod file, change the Sub/Func/Procedure name to "F" for
function, or "S" for Sub. The module file name is already the original
actual procedure name.
6. Now loop thru original VB6 sources and look for any occurrence of
"myFuncName" or" mySubName"...and change to "myFuncName.F" or
"mySubName.S" This was the easiest way I could think of for name the
new module files in the most practical way.
7. Go thru sources and update myArray(..) to myArray[..]. Any VB6
declare of myArray(0 to n) gets converted to a Gambas declare
And so on. I'll have to figure out more as I go. Perhaps Forms will
have to be manually re-constructed to match as much as possible with the
original VB6 form.
This plan might turn out to be an absolute piece of shit when I get to
the bigger project. But it looks hopeful for at least the code
sections. Maybe not so much for forms.
The concept is that current VB6 code logic works perfectly, and we want
to preserve as much of that as possible without making huge changes -
and as far as the machine operators are concerned they won't see much
change from a Windows to Linux machine. 99.9% of the time they are
looking at the full screen GUI display anyway, and they really don't
interact with the OS on a desktop or terminal level. As long as they
can run the machine, and maybe open up a Firefox web browser, use PDF
viewer for help files, or get to LibreOffice for looking at report
spreadsheets, that's all they need. They don't even need to know there
is no "C:" drive anymore.
More information about the User