Compiled If...Then does not work like in ide!
in [Visual Basic]
|
Prev: Activate the first input element
Next: One Shot Timers
From: Nobody on 30 Jun 2010 03:27 "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) = What's the data type of rlineGetDevCaps? If it's an API function, post the declaration. Have you printed the actual values of what the IDE sees and when running the EXE? They could be different. To use something like "Debug.Print" in the EXE, you need to use some alternative, like OutputDebugString(), or the wrapper function "DebugPrint" below, which allows you to print from both the IDE and the EXE without changing the code. To view OutputDebugString output, use this free software, which doesn't require installation: DebugView: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx Declaration: Public Declare Sub OutputDebugString Lib "kernel32" Alias _ "OutputDebugStringA" (ByVal lpOutputString As String) Usage: OutputDebugString "ABC" Wrapper sub: Public Sub DebugPrint(ByRef s As String) Debug.Print s OutputDebugString s & vbCrLf End Sub
From: Ulrich Korndoerfer on 30 Jun 2010 04:17 Hi Claire, Claire schrieb: > 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. ... Your code effectively boils down to If CondA And CondB Then ... Now the And logical operator is commutative, that is "CondA And CondB" and "CondB And CondA" both deliver the same result. 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. In your example the result of CondB *depends* on CondA and CondA must be evaluated first. However, as said, this is not guranteed by VB. If CondA Then If CondB Then is the only viable way to guarantee that CondA is evaluated first. -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.prosource.de/Downloads/ MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
From: Mike Williams on 30 Jun 2010 04:18 "Claire" <replyto(a)fra> wrote in message news:uSghQRAGLHA.6120(a)TK2MSFTNGP04.phx.gbl... > BTW, pcode compilation creates almost twice > smaller executable and compilation process is > much faster! The ompilation processs might be much faster (because it has less work to do) but the speed of the code in the compiled exe willgenerally not be. Generally, if your code is repeatedly accessing the properties of controls or repeatedly using coded or implied data type conversions or is performing other similar "bottom heavy in pcode" stuff then there won't be much difference between the speed of pcode and the speed of native code, but if you are performing lots of number crunching or data manipulation and similar "top heavy in pcode" operations then native code is generally much faster than pcode. Many funtions you write will run ten or more times faster as a native code compiled exe. It's horses for courses really. Depends what you are doing. Mike
From: ralph on 30 Jun 2010 08:03 On Wed, 30 Jun 2010 10:17:39 +0200, Ulrich Korndoerfer <ulrich_wants_nospam(a)prosource.de> wrote: >Hi Claire, > >Claire schrieb: >> 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. ... > >Your code effectively boils down to > >If CondA And CondB Then ... > >Now the And logical operator is commutative, that is "CondA And CondB" >and "CondB And CondA" both deliver the same result. > >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. > >In your example the result of CondB *depends* on CondA and CondA must be >evaluated first. However, as said, this is not guranteed by VB. > >If CondA Then > If CondB Then > >is the only viable way to guarantee that CondA is evaluated first. That's interesting and should be easy to test. The OP might try a native code compile with optimization turned off and coerce 'non-rearranging' by including the debug symbols file. If the debug version runs correctly it would suggest that it is indeed later optimization passes by the C compiler that is causing the mis-translation, rather than the VB prepreprocessor. Curious to see the results. -ralph
From: dpb on 30 Jun 2010 08:47
ralph wrote: > On Wed, 30 Jun 2010 10:17:39 +0200, Ulrich Korndoerfer > <ulrich_wants_nospam(a)prosource.de> wrote: > >> Hi Claire, >> >> Claire schrieb: >>> 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. ... >> Your code effectively boils down to >> >> If CondA And CondB Then ... >> >> Now the And logical operator is commutative, that is "CondA And CondB" >> and "CondB And CondA" both deliver the same result. >> >> 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. >> >> In your example the result of CondB *depends* on CondA and CondA must be >> evaluated first. However, as said, this is not guranteed by VB. >> >> If CondA Then >> If CondB Then >> >> is the only viable way to guarantee that CondA is evaluated first. > > > That's interesting and should be easy to test. > > The OP might try a native code compile with optimization turned off > and coerce 'non-rearranging' by including the debug symbols file. If > the debug version runs correctly it would suggest that it is indeed > later optimization passes by the C compiler that is causing the > mis-translation, rather than the VB prepreprocessor. > > Curious to see the results. Also, another tidbit I forget...does VB short-circuit? If, indeed, the OP's posting means as it seems to imply that there are side effects in the function that's a _generally_bad_thing_ (tm) owing to potentially giving rise to such "features" as seeing here. So far, insufficient data for any firm conclusions but I'd still lean towards the code being questionable over the compiler being wrong until shown different... I've had cases where the VB compiler failed to complete a compilation that were reproducible when occurred but to date I've never found an actual compilation bug. Not to say there aren't some or is impossible, but it's certainly not the most likely culprit here imo... -- |