Thomas,

Thank you for your reply. However, the variables are all declared as globals if
you are talking about the first situation (type mismatch when calling a sub).
Because my subs usually call other subs, I use a lot of global variables.
Apparently that is not the problem.

Jim


--- In nsbasic-desktop@yahoogroups.com, Computerhusky <computerhusky@...> wrote:
>
> Hi Jim,
> you're not declaring any variables you use in your sub, so they should be
global or the SUB won't work. I suggest you put "option explicit" right at the
beginning of your program and DIM all variables.
> Remember that all variables are local and are known only inside the sub or
function where they are declared (dim) or assigned a value!
> Kind regards
> Thomas
> Von meinem iPhone gesendet
>
> Am 11.07.2009 um 22:49 schrieb "cschuchert" <cschuchert@...>:
>
>
>
> Something isn't right here and hope someone might have an insight into what
may be causing it. It could be a bug in NSB Desktop, itself, or something I have
done but my lack of expertise prevents my seeing it. I reported a similar
situation in this forum and the response was it must be in the code and keep
looking. Here is what is happening occasionally but not always:
>
> I call a sub in a module from my code. When it gets to that code line, it
complains there is a type mismatch. I put a debugging msgbox at the beginning of
the sub and try again but it never gets that far, like it doesn't think the sub
is there. It stops at the code line and gives the mismatch error. I realize that
if the sub is not in the module, that will happen but that isn't the case. The
sub is there. A few days ago I posed the question about "is there a limit to
number of subs allowed in a module" to which the reply was there is not.
Nevertheless, I removed the sub, created a new module and pasted it to the new
one. It then found the sub and all was ok. Now it happened again and my first
solution doesn't work. Consider this:
>
> Sub Displayinverse
> If intAZ Then
> strNS = ""
> strEW = ""
> End If
> pintcntr = InStr(strFrpoint, "*")
> plngPtfrom = Int(Mid(strFrpoint, 1, pintcntr - 1))
> plngPtto = Int(Mid(strFrpoint, pintcntr + 1))
> pstrBrng = strNS & strDeg & Chr(176) & strMin & Chr(39) & strSec & Chr(34) &
strEW
> pstrDist = FormatNumber(dblDistance, sDecPl)
> txtembedDisplay.Text = txtembeddisplay.Text & plngPtfrom & " " & _
> pstrbrng & " " & pstrdist & vbCrLf
> End Sub
>
> I placed this sub in Module 1 and tried to call it from the following code:
> Sub lenfrpoint1()
> continueinverse
> If intAZ Then dblBearingdms = dblBearing
> If dblBearing = 90 Or dblBearing = 270 Then dblBearingdms = 90
> converttodms
> displayinverse `the one I was calling
> End Sub
>
> It gave the `type mismatch' message
>
> I deleted it from Module 1 and put it in Module 2 with the same results.
>
> Then I copied the code within `displayinverse' and substituted if for the sub,
like this:
> Sub lenfrpoint1()
> continueinverse
> If intAZ Then dblBearingdms = dblBearing
> If dblBearing = 90 Or dblBearing = 270 Then dblBearingdms = 90
> converttodms
> If intAZ Then
> strNS = ""
> strEW = ""
> End If
> pintcntr = InStr(strFrpoint, "*")
> plngPtfrom = Int(Mid(strFrpoint, 1, pintcntr - 1))
> plngPtto = Int(Mid(strFrpoint, pintcntr + 1))
> pstrBrng = strNS & strDeg & Chr(176) & strMin & Chr(39) & strSec & Chr(34) &
strEW
> pstrDist = FormatNumber(dblDistance, sDecPl)
> txtembedDisplay.Text = txtembeddisplay.Text & plngPtfrom & " " & _
> pstrbrng & " " & pstrdist & vbCrLf
> End Sub
>
> That works fine. Now what in the world could be causing the `type mismatch'
when calling the sub from the code? This sub (displayinverse) is not many lines
of code but I have others with a great number of lines and don't want to paste
them. Could it be the copying and pasting operation from VB to NSB? I also have
done the same thing from the CE version and believe the first problem was from
one those pastings. A real conundrum!
>
> I am also finding that using the variant type may be causing problems when
comparing values. My if...then clauses using > and < in comparing values gave me
bad results because it apparently wasn't comparing numbers with what it may have
considered strings. As soon as I placed `Int' in front of the value (which I
thought the variant type recognized as a double) it worked but not in all cases.
>
> I may kick myself when I discover how simple the problem presented really is
so I look forward to that kick. Thanks for reading through this long post.
>
> Jim
>