[RESOLVED] Properly referring to data / subs inside a module
I am asking a general question. I have a long code and I am getting an error message " Procedure too large". I guess I need to divide my code into some subroutines / modules.
For example if I have a code with bunch of variables predefined as follows:
Code:
Private Sub cmdreadQEA_Click()
Dim DataString As String
Dim Plus As Long, Equals As Long, Comma As Long
'Dim varname As String, VarVal As String
Dim outfile As String
Dim numline As Integer
Dim myLine As String
Dim y As Integer
Dim numLinesWithPlusSign As Integer
Dim strFile As String
Dim NSQIJM As Integer
'Dim varname1() As String
' Dim varval1() As String
Label1 = NQSIJM
ReDim NQSMUL(NSQIJM), NQSMF(NSQIJM)
' *********************************************************************************
' Data from friend
' *********************************************************************************
ISRESTO = -1
ISPAR = 0
ISLOG = 1
ISDIVEX = 0
ISMMC = 0
ISHP = 0
ISHOW = 0
'C3
RP = 1.8
RPADJ = 1.8
RSQMADJ = 1E-16
ITRMADJ = 1000
ITERHPM = 0
ISDSOLV = 0
FILT3TL = 0.0625
'C4
ISSSMMT = 0
ISLTMTS = 0
ISIA = 0
RPIA = 1.8
RSQMIA = 0.0000000001
ITRMIA = 1000
'C5
ISCDMA = 0
ISHDMF = 1 ' To turn off diffusion set this to 0.
ISDISP = 0
ISWASP = 0
ISQQ = 1
ISRLID = 0
ISVEGL = 0
ISEVER = 0
'C6
For i = 0 To 8
ISTOPT(i) = 0
ISCDCA(i) = 0
ISPLIT(i) = 0
ISADAH(i) = 0
ISADAV(i) = 0
ISCI(i) = 0
ISCO(i) = 0
Next
End Sub
I have skipped several lines of code above and below the original subroutine. What I want to know is how can I separate the variables from 'C3 to the end of file and then copy these to a separate file and then refer them to the main subroutine. I tried creating a subroutine and used the code "Call sub trial()" (for eg) but it didn't work. I tried to export those data to module but it says "invalid outside procedure". Would someone suggest the best approach ?
Re: Properly referring to data / subs inside a module
Yes there is a limit to how big a procedure [sub/function] can be.
It is good practice to limit the size well below the limit. As a general rule of thumb it is good to keep a procedure short enough to fit on the screen so you can see the whole thing at once though this is not always possible.
So yes you would likely want to break it into more than one sub be it within the form code or within a module.
Can't say where you should break it up but it looks like all those lines that are setting values to vars are dealing with non local [or undefined] vars if they are non local then that code could reside in a separate sub and then just add a call to that sub.
Re: Properly referring to data / subs inside a module
I had a big program and now I have divided into modules and subs. I have a main program and in that main program I have called the subroutine which is supposed to take the variables in the main program. However, the variables are not being passed to the subroutine. Any suggestions on what are the locations that I need to check at first ?
Re: Properly referring to data / subs inside a module
You need to be clear what you are talking about here. I have a feeling you do not mean passing these vars to the subs but rather accessing them from the subs.
To pass a var to a sub you use arguments.
Code:
Private Sub SomeSub(VarA as String, VarB as Integer, VarC as Long)
You would then pass the vars or data when you call the sub
Code:
somesub "Some Text", 14,2024
To access vars across subs without passing them they have to be dimmed at the correct level.
Local vars can only be accessed from within the routine where they are dimmed.
Vars dimmed in the declarations sections can be accessed;
by any code in the form/class or module if they are set as Private
by any code in the project if they are set as Public. In the case of forms and classes there are additional requirements
Public vars in a class that is part of a dll or user control can be accessed outside the original project by other projects that make use of the dll or UC
Re: Properly referring to data / subs inside a module
Thank you so much for the detailed clarification. I will check all the variable and find out if they are properly dimmed at correct level.