From: ralph on
On Wed, 30 Jun 2010 07:47:47 -0500, dpb <none(a)non.net> wrote:


>
>Also, another tidbit I forget...does VB short-circuit?
>

No, it does not.

[As a sidenote, a lack of short-circuiting was often used in the old
days by VC programmers as a point towards demonstrating the inferior
qualities of VB. However, while often saving clicks at runtime,
"short-circuiting" has the occasional Gotcha! as well. <g>]

Without more information about the exact code the OP is using, it is
impossible to duplicate or to make anything but the broadest of
guesses, but my money is on the optimizer getting confused with all
that sharing between the operants. Thus the later optimizing compiler
is the likely curprit. However, there are very good reasons I stay out
of Casinos. <g>

Then again, a simple project cleanup, a minor re-arrangement, and the
error/anomaly may simply disappear - Has happened before.

-ralph
From: dpb on
ralph wrote:
> On Wed, 30 Jun 2010 07:47:47 -0500, dpb <none(a)non.net> wrote:
>
>
>> Also, another tidbit I forget...does VB short-circuit?
>>
>
> No, it does not.
....

I didn't really think so, but didn't recall for certain.

> Without more information about the exact code the OP is using, it is
> impossible to duplicate or to make anything but the broadest of
> guesses, but my money is on the optimizer getting confused with all
> that sharing between the operants. Thus the later optimizing compiler
> is the likely curprit. However, there are very good reasons I stay out
> of Casinos. <g>
>
> Then again, a simple project cleanup, a minor re-arrangement, and the
> error/anomaly may simply disappear - Has happened before.
>
> -ralph

OP said they're still on VB5; my money is not on the optimizer being
"confused" but the code as written being the underlying culprit.

In Fortran, it would be by the formal Standard "illegal" code but of the
type of violation for which the onus is on the programmer to "don't do
that!" as opposed to the compiler being required (or even able, often)
to detect the violation. The VB, programmer otoh, w/o the formality of
there being a published Standard doesn't have the benefit of knowing
they may have violated a proscription, even, unfortunately.

My money is still on something very similar as that previously
hypothesized but it is, as noted by both of us and others, still too
little detail available to be able to say anything definitively about.

Will be interesting if OP ever comes back and fleshes out the details to
discern what really is going on.

--
From: ralph on
On Wed, 30 Jun 2010 09:29:43 -0500, dpb <none(a)non.net> wrote:


>
>OP said they're still on VB5; my money is not on the optimizer being
>"confused" but the code as written being the underlying culprit.
>
>In Fortran, it would be by the formal Standard "illegal" code but of the
>type of violation for which the onus is on the programmer to "don't do
>that!" as opposed to the compiler being required (or even able, often)
>to detect the violation. The VB, programmer otoh, w/o the formality of
>there being a published Standard doesn't have the benefit of knowing
>they may have violated a proscription, even, unfortunately.
>

There was very little change in the "core" language between VB5 and
VB6 with the exception of a few more new functions. (Most of the
changes dealt with the OLE engine and new controls.)

However, one always has to note that VB6 also included "bug fixes",
but since the VB IDE/Parser has always been a 'blackbox' - not all
such fixes were acknowledged thus this might just be one them.

Also, there were some dramatic changes in the optimizing C compiler
with VS6 (or rather C v12). Should the evidence point to the C2
compiler then we would also have to look at that version.

>My money is still on something very similar as that previously
>hypothesized but it is, as noted by both of us and others, still too
>little detail available to be able to say anything definitively about.
>
>Will be interesting if OP ever comes back and fleshes out the details to
>discern what really is going on.

Yeah, it would. With the Holiday coming up I'm probably not the only
geek with no life and some time to play. <g>

-ralph
From: Karl E. Peterson on
After serious thinking Ulrich Korndoerfer wrote :
> So VB is free to compute CondA first or CondB. VB does not guarantuee any
> sequence. Especially when compiling to native code, the compiler may shuffle
> execution sequences around for optimizing purposes.

Beat me to it. NEVER use both a function and the result of that
function within the same IF test. You're just *asking* to be spanked!

--
..NET: It's About Trust!
http://vfred.mvps.org


From: Claire on
Thank you all for all that lively discussion.
For all people interested in more details please find the corresponding
code.
However, it may not be simple for you fo trace it. The following code uses
TAPI interaction with the modem (TAPI device)
============================
Declare Function lineGetDevCaps Lib "TAPI32.DLL" (ByVal hLineApp As Long,
ByVal dwDeviceID As Long, ByVal dwAPIVersion As Long, ByVal dwExtVersion As
Long, lpLineDevCaps As LINEDEVCAPS) As Long

Type LINEDEVCAPS
dwTotalSize As Long
dwNeededSize As Long
dwUsedSize As Long

dwProviderInfoSize As Long
dwProviderInfoOffset As Long

dwSwitchInfoSize As Long
dwSwitchInfoOffset As Long

dwPermanentLineID As Long
dwLineNameSize As Long
dwLineNameOffset As Long
dwStringFormat As Long

dwAddressModes As Long
dwNumAddresses As Long
dwBearerModes As Long
dwMaxRate As Long
dwMediaModes As Long

dwGenerateToneModes As Long
dwGenerateToneMaxNumFreq As Long
dwGenerateDigitModes As Long
dwMonitorToneMaxNumFreq As Long
dwMonitorToneMaxNumEntries As Long
dwMonitorDigitModes As Long
dwGatherDigitsMinTimeout As Long
dwGatherDigitsMaxTimeout As Long

dwMedCtlDigitMaxListSize As Long
dwMedCtlMediaMaxListSize As Long
dwMedCtlToneMaxListSize As Long
dwMedCtlCallStateMaxListSize As Long

dwDevCapFlags As Long
dwMaxNumActiveCalls As Long
dwAnswerMode As Long
dwRingModes As Long
dwLineStates As Long

dwUUIAcceptSize As Long
dwUUIAnswerSize As Long
dwUUIMakeCallSize As Long
dwUUIDropSize As Long
dwUUISendUserUserInfoSize As Long
dwUUICallInfoSize As Long

MinDialParams As LINEDIALPARAMS
MaxDialParams As LINEDIALPARAMS
DefaultDialParams As LINEDIALPARAMS

dwNumTerminals As Long
dwTerminalCapsSize As Long
dwTerminalCapsOffset As Long
dwTerminalTextEntrySize As Long
dwTerminalTextSize As Long
dwTerminalTextOffset As Long

dwDevSpecificSize As Long
dwDevSpecificOffset As Long

dwLineFeatures As Long ' ADDED BY RICK CHECKETTS
mem As String * 2048 ' ADDED BY MCA
End Type
''''------------------------------
Public Function rlineGetDevCaps(ByVal Line As Long) As Boolean
Dim b As LINEDEVCAPS

b.dwTotalSize = Len(b)
rtn = lineGetDevCaps(hTapi, Line, m_APIversions(Line),
m_Extversions(Line), b)
If rtn = &H8000000C Then 'LINEERR_INCOMPATIBLEAPIVERSION
rtn = lineGetDevCaps(hTapi, Line, &H10004, m_Extversions(Line), b)
End If
If rtn = 0 Then
If b.dwMediaModes And (LINEMEDIAMODE_DATAMODEM Or
LINEMEDIAMODE_INTERACTIVEVOICE Or LINEMEDIAMODE_G3FAX) Then rlineGetDevCaps
= True '_INTERACTIVEVOICE for SIP, _G3FAX for Hi-Phone
ProviderName = GetVarInfo(Clean(b.mem), (b.dwProviderInfoOffset -
LINEDEVCAPS_FIXEDSIZE) + 1, b.dwProviderInfoSize - 1)
LineName = GetVarInfo(Clean(b.mem), (b.dwLineNameOffset -
LINEDEVCAPS_FIXEDSIZE) + 1, b.dwLineNameSize - 1)
If LCase(LineName) = "ipconf line" Or LCase(LineName) = "h323 line"
Then rlineGetDevCaps = False
If rlineGetDevCaps = True Then
MediaMode = b.dwMediaModes
lpNumAddresses = b.dwNumAddresses
sAddressMode = b.dwAddressModes
MonitorTones = b.dwMonitorDigitModes
LineID(Line) = b.dwPermanentLineID
End If
Else
Debug.Print "rlineGetDevCaps: " & Hex(rtn)
End If
End Function
===============================================================================

''''If you are sure you want to run it and go to the depth of it you need to
preceed the :rlineGetDevCaps() with the following function:


'''1.
Declare Function lineInitializeEx Lib "TAPI32.DLL" Alias "lineInitializeExA"
(ByRef lphLineApp As Long, ByVal hInstance As Long, ByVal lpfnCallback As
Long, ByVal lpszFriendlyAppName As String, ByRef lpdwNumDevs As Long, ByVal
lpdwAPIVersion As Long, ByRef lpLineInitializeExParams As
LINEINITIALIZEEXPARAMS) As Long
Public Const LINEINITIALIZEEXOPTION_USEHIDDENWINDOW As Long = &H1
'// TAPI v2.0
Type LINEINITIALIZEEXPARAMS
dwTotalSize As Long
dwNeededSize As Long
dwUsedSize As Long
dwOptions As Long
hEvent As Long 'union hEvent and Completion port
dwCompletionKey As Long
End Type

Public Sub rlineInitialize()
Dim i, j As Long
Dim adrLineCallBack As Long
Dim lip As LINEINITIALIZEEXPARAMS

adrLineCallBack = PtrToLong(AddressOf LINECALLBACK)
lLineInst = GetModuleHandle(vbNullString)
lip.dwTotalSize = Len(lip)
lip.dwOptions = LINEINITIALIZEEXOPTION_USEHIDDENWINDOW

'initialize TAPI lines and get handle (hTapi)
'
dim hTapi, lLineInst, lpNumLines as Long
rtn = lineInitializeEx(hTapi, lLineInst, adrLineCallBack, App.Title,
lpNumLines, &H10004, lip)
End Sub


'''2.
'''The obtained value hTapi from above must be fed into lineGetDevCaps() API
'''To make it simpler, you can run that API with the following parameters:
rtn = lineGetDevCaps(hTapi, 0&, &H10004, &0, b)
'''and of course do not use array but this:
dim LineID as Long
LineID = b.dwPermanentLineID

'''Hope, I am clear on that.
'''Thanks,
'''Claire

"Claire" <replyto(a)fra> wrote in message
news:Ofp6qZ%23FLHA.1996(a)TK2MSFTNGP06.phx.gbl...
> Hello,
> I have just came across this problem:
> This line of code:
> If rlineGetDevCaps(l) = True And LineID(l) =
> Val(Mid(sSelectLines, i + 4, k - i)) Then
> (some code here)
> Else
> MsgBox "Lines have changed since the last use.",
> vbExclamation, "Line Error"
> End If
>
> rlineGetDevCaps(l) is the function and LineID(l) is one of parameters
> returned by that function
>
> This line of code works properly in development stage but when compiled it
> does not.
> Despite both conditions met the msgbox is displayed.
> Why that works in ide but not when compiled?
>
> I corrected the problem by splitting the conditions:
> If rlineGetDevCaps(l) = True Then
> If LineID(l) = Val(Mid(sSelectLines, i + 4, k - i))
> Then
> (some code here)
> Else
> MsgBox "Lines have changed since the last
> use.", vbExclamation, "Line Error"
> End If
> End If
>
> but I wonder if that is a common problem?
> Your input appreciated,
> Claire
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Activate the first input element
Next: One Shot Timers