Prev: Activate the first input element
Next: One Shot Timers
From: ralph on 30 Jun 2010 10:13 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 30 Jun 2010 10:29 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 30 Jun 2010 12:04 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 30 Jun 2010 12:50 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 30 Jun 2010 14:36
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 > |