ini files 2

[fergmj]

I have an app that uses an ini file to store folder paths, com port numbers, and file extensions.

I am able to read from the ini file fine when I do this:

Private Sub Form_Load()
Call getin
comport = ia 'comm port for serial communications
End Sub

Private Sub getin()
ia = "": 'process comments in audiorelay.ini
1 If EOF(1) Then GoTo 2 ' check for eof
Line Input #1, ia 'get line
' if is does not have a comment code then return it
If Left$(ia, 1) <> &quot;'&quot; Then GoTo 2
GoTo 1
2 '
End Sub

However....when I MsgBox (comport) in another subroutine, i get a blank box and nothing as its value. i can MsgBox (comport) after calling the value from the ini file and all is fine, but try to use the comport in another routine and it is empty.

Note, I have an ini file with only about 15 lines of text in it and the first several (4 or so) work fine by calling them elsewhere in the app but the later ones do not.

Any ideas?

fergmj

 

[Ruairi]

Where and how is the variable comport defined? it sounds like it's out of scope in the subroutine in question. You should define variables that are used throughout your program in a module, not in a form or procedure. Ruairi

Could your manufacturing facility benefit from real time process monitoring? Would you like your employees to be able to see up to the minute goal and actual production?
For innovative, low cost solutions check out my website.

http://www.plccontroltechnologies.com

 

[fergmj]

Can you explain what you mean by out of scope and defining in a module?

I define it by Dim comport As String

Thanks

fergmj

 

[SBGibson]

The life of a variable depend on how and where it's defined.
If you use comport only on that form you should define it in the [Declaration] section of the form.
But if you want to use comport in all your application you must define in into the [declaration] section of a module (you can insert a module with project/Add module menu item).
It's possible that the problem is due to that cause? Stevie B. Gibson

 

[Ruairi]

Heres a quick crash course on variable scope:
There are 3 basic places to define a variable (there are actually quite a few more but these are the commonly used ones)
1) Inside a procedure:

------ Start of code for FirstForm 
Option Explicit

Private Sub MyProcedure() 
   Dim comport As String 

   comport = "COM1"
End Sub 

Private Sub AnotherProc() 
    
    MsgBox comport 
End Sub
----- End Of Code for FirstForm -----

The scope of this variable is MyProcedure().
This comport variable is only 'Alive' inside the MyProcedure procedure. As soon as execution moves outside this procedure the variable is no longer defined. If you come back to the procedure later a new copy of the variable is created. Trying to use comport in AnotherProc() as i do here will do one of two things: if you have Option Explicit typed as the first thing in the forms code (as i do here) you will get a variable not defined or unknown identifier error. If you do not have Option Explicit typed in the forms code a comport variable will be created in AnotherProc
even though it's name is the same it is a different variable than the comport in MyProcedure() because that variable is out of scope and no longer exists. The MsgBox will be blank
2) In the declaration section of a form:

------ Start of code for FirstForm 
Option Explicit 

Dim comport As String 

Private Sub MyProcedure() 

    comport = "COM1"
End Sub

Private Sub AnotherProc() 

    MsgBox comport 
End Sub
----- End Of code for FirstForm

The scope of this variable is the form.
This comport variable, because it was defined outside of any procedures, is 'Alive' as long as the form is. The MsgBox called in AnotherProc() will display COM1, because it is looking at the same comport variable as MyProcedure().

3) In the declaration section of a module:

---------Start of Module1 code ----------- 
Dim comport As String 

---------End Of Module1 code ------------

------ Start of code for FirstForm 
Option Explicit 

Private Sub MyProcedure() 

    comport = "COM1"
End Sub

Private Sub AnotherProc() 

    MsgBox comport 
End Sub
----- End Of code for FirstForm 

----- Start of code for SecondForm ------
Option Explicit 

Private Sub Form2Proc() 
    
    MsgBox comport 
End Sub 
----- End Of code for SecondForm

The scope of this variable is the entire program.
Even Form2Proc() is looking at the same comport varable that MyProcedure() set in the first Form. That is because the variable was defined outside any forms, in a module. This is how you would want to define your variable, that way your whole program can see it.

There is actually a lot more to scope than this, and in fact a variable defined as Public (instead of Dim) in one form CAN be seen in other forms but this should be enough to tell you where your problem is and start to understand the concept of scope.
HTH

Ruairi

Could your manufacturing facility benefit from real time process monitoring? Would you like your employees to be able to see up to the minute goal and actual production?
For innovative, low cost solutions check out my website.

http://www.plccontroltechnologies.com

 

[fergmj]

i only have one form in the app and it is declared at the beginning of the app in the declaration section as with all of the other variables that work.

fergmj

 

[alistairpaul]

Just a thought - Here's what I experimented with.
======================================================
Private Sub Form_Load()
Call getin
comport = ia
MsgBox comport
MsgBox ia
End Sub

Private Sub getin()
ia = &quot;hello&quot;
MsgBox ia
End Sub
======================================================
In this scenario, &quot;msgbox comport&quot; and &quot;msgbox ia&quot; in Form_Load brought back NO VALUE. While &quot;msgbox ia&quot; in getin() brought back the value.

======================================================
Dim ia As String
Dim comport As String

Private Sub Form_Load()
Call getin
comport = ia 'comm port for serial communications
MsgBox comport
End Sub

Private Sub getin()
ia = &quot;hello&quot;
MsgBox ia
End Sub
======================================================
In this scenario, all &quot;msgbox&quot; statements brought back a value.

Perhaps you should try changing your getin() sub to a function. Instead of setting your requested value into a variable that you have to worry about its scope, you should set getin=&quot;requestedvalue&quot; and just use the function's return as your value in the other procedures.

 

[fergmj]

That worked wonders. Thanks

fergmj

 

[SBGibson]

Excuse me but I don't understand...the only difference is that in the second way the variables are declared in the top of the application....it's not the same thing we was saying ? Stevie B. Gibson

 

[petermeachem]

Alastair has declared the variables in the form general section. Meaning that anything in the form can get at them. Peter Meachem
peter@accuflight.com

 

[alistairpaul]

It is the same thing, SBGibson, but the changing of the sub to a function might make life easier.

Instead of:
call getin
comport = ia

You could just do:
comport = getin

As long as you changed the sub to a function and returned what would be &quot;ia&quot; as the function return value.

 

[petermeachem]

In your first example you have not defined the variables, in the second you have. In the second that are still subroutines.

Please everyone, Always put Option Explicit at the top of every module form or whatever. Then you have to define things properly. Peter Meachem
peter@accuflight.com

 

[SBGibson]

Ehehe, I created a Case
I agree with the solution of the function. I was only saying that the problem was the scope of variables 'cause, as you denmostrate, declaring variables at the top of the form all works well. Stevie B. Gibson