Compiled If...Then does not work like in ide!
in [Visual Basic]
|
Prev: Activate the first input element
Next: One Shot Timers
From: Claire on 29 Jun 2010 23:23 I experimented with the brackets but to no avail. I tried this: If (rlineGetDevCaps(l) = True) And (LineID(l) = Val(Mid(sSelectLines, i + 4, k - i))) Then and this: If rlineGetDevCaps(l) = True And (LineID(l) = Val(Mid(sSelectLines, i + 4, k - i))) Then Thanks, Claire "Henning" <computer_hero(a)coldmail.com> wrote in message news:i0e840$v29$1(a)news.eternal-september.org... > > "Claire" <replyto(a)fra> skrev i meddelandet > 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 >> > > The compiler might see it different than the ide. I've used squarebrackets > to visualize. > 1. > If [rlineGetDevCaps(l) = True And LineID(l)] = > Val(Mid(sSelectLines, i + 4, k - i)) Then > > 2. > If [rlineGetDevCaps(l) = True] And [LineID(l) = > Val(Mid(sSelectLines, i + 4, k - i))] Then > > Does added parens make any difference? > If (rlineGetDevCaps(l) = True) And (LineID(l) = > Val(Mid(sSelectLines, i + 4, k - i))) Then > > I agree with Duke about readability. ;) > > /Henning > >
From: Claire on 29 Jun 2010 23:28 BTW, pcode compilation creates almost twice smaller executable and compilation process is much faster! I am using vbasic 5. Claire "ralph" <nt_consulting64(a)yahoo.net> wrote in message news:ldal26t2ttk2jfuhsi1gjba5t3oepd87jr(a)4ax.com... > On Tue, 29 Jun 2010 19:54:16 -0400, "Claire" <replyto(a)fra> wrote: > >>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 >> > > Curious. What happens if you compile to pcode?
From: dpb on 30 Jun 2010 00:26 Claire wrote: > 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 .... > 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? .... Not sure otomh w/o some digging but... I'd want to see the declarations for the function and variables at a minimum for starters...also where is "True" defined and as what? The indication that "rlineGetDevCaps(l) is the function and LineID(l) is one of parameters returned by that function" makes me wonder about side effects and such... Which optimizations, if any, did you use in the compilation? My supposition, btw, if you can't tell from the questions is that the function is coded on the basis of True==!0 whereas the keyword definition of True is == -1 or a similar mismatch. It's entirely plausible the code to test is not the same in the IDE/pcode as in compiled and that could be the difference. I'd be looking at loose coding style before actual code generation error first before I decided it is actually not a programming foobar, though. --
From: ralph on 30 Jun 2010 01:08 On Tue, 29 Jun 2010 23:28:29 -0400, "Claire" <replyto(a)fra> wrote: >BTW, pcode compilation creates almost twice smaller executable and >compilation process is much faster! >I am using vbasic 5. >Claire > It is also produces generally faster programs, such as basic client Windows App that is Forms/Controls/Navigation intensive - opposed to a more "computational" program where a lot of number crunching or data shuffling is required. If size is important use pcode. While a pcode compile is faster to compile, IMHO faster compiles are only useful during development. *Speed* is useful as a feature of the finished product - and for that you will always have to test. There have been several "bugs" reported over the years between pcode and native compiles, and most of them seem to be related to logical operators or to the occasional odd Interface dereferencing. Exactly why I'm not sure. I think I knew once upon a time but all that was 12+ years ago. <g> For the other differences, that is relatively easy to explain. VB isn't like many other programming languages we are familar with, like C for example. Where the "compile" process is reasonably straight-forward. You write in a particular language in a text file, submit the text file to the compiler where it is read (parsed) and then through several passes converted to native code. "VB" itself is actually pcode. The written portion of the lanuage is only a user-friendly script used as a front-end to feed the VB Editor/Parser to produce pcode. For example, when you load a VB file into the VB editor it is immediately parsed and converted to pcode, while actually "running" in the background VM. What you see on the screen is only an artifact. (This was more evident in earlier versions where all files were saved as pcode. In order to get a human-readable text file, you had to specifically request a save in that format. Which was actually a sort of de-compile. You can also glimpse how the parser works while editing and making changes - note how quickly VB notices case changes, or performs validity checking. Or in the responsiveness of the intermediate window and how any changes in values made there are immediately reflected in the "running" code.) When you run code in the IDE, you are running pcode. When you make changes - you are actually changing pcode. Pcode itself is not just line-by-line tokenized statements, but actually is an accumulation of various table and caches with a stack-based running "thread" - quite similar to Forth. When you compile a program to pcode, the IDE merely has to convert it from opcode to excode, slap on some runtime packages (link), and Bang! you're ready to go. To compile to native code, the IDE takes the internal pcode and converts it to pre-processed "C" code files, which is then passed on the C second-pass compiler, and so on. hth -ralph
From: ralph on 30 Jun 2010 01:24
On Tue, 29 Jun 2010 23:28:29 -0400, "Claire" <replyto(a)fra> wrote: If you have basic C skills and are really nosey you can probably pin-point the exact transition problem by viewing the generated pre-processed C file. To do this, temporarily replace the C2.exe compiler with a VB program of your own making that simply reads the command line and then pauses. The VB IDE when it compiles to native code will create the pre-processed files. They will be in the project folder and will have a .obj extension (though they are not .obj files as defined by C). Find the one that relates to the translation unit of interest and open it up in a text editor. You should see something interesting, however your original statement contains quite a lot of redirection - so expect to do a bit of detective work. -ralph |