Compiled If...Then does not work like in ide!
in [Visual Basic]
|
Prev: Activate the first input element
Next: One Shot Timers
From: dpb on 1 Jul 2010 09:13 Claire wrote: > "dpb" <none(a)non.net> wrote in message > news:i0gbdm$uah$1(a)news.eternal-september.org... >> Claire wrote: >>> "dpb" <none(a)non.net> wrote in message >>> news:i0g49n$j4a$1(a)news.eternal-september.org... >>>> Claire wrote: >>>> >>>> ...[top posting repaired...don't do that; hard follow conversation >>>> make]... >>>> >> ... >> >>> lineGetDevCaps () is API function used by my function called: >>> rlineGetDevCaps () >>> I thought until now I can create my own function as I like it and I do >>> not need to consult SDK about that. >> ... >> >> OK, sorry, I did, in fact, overlook the rLine... >> >> It looks ok in that it is declared Boolean except... >> >> 1) This is a nit but I'd initialize rlineGetDevCaps = False on entry just >> as good practice. It isn't the problem; not saying it is... >> >> 2) Second nit--since it does return a Boolean, the test >> >> If rlineGetDevCaps(l) = True And LineID(l) = ... >> >> might better be written as >> >> If rlineGetDevCaps(l) And LineID(l) = ... >> >> Again, it isn't the actual problem but still a Boolean is a logical >> already. >> >> 2) I don't see where lineID() is returned anywhere??? Ergo, it's a >> Global array? I (as others noted) don't like the side effects that way >> and it looks like there are paths that it doesn't get updated in the >> function? Any possibility there's a logic flaw there somehow? >> >> At a minimum I'd return a used value in the argument list I believe and at >> least reconsider refactoring the function. >> >> -- > Yes, LineID() is a global array and if you have a closer look at the > rlineGetDevCaps () routine you'd find it in there. > For me Ulrich Korndoerfer's reply sounds reasonable. I saw it _IN_ the routine; I said I didn't see it _RETURNED_ from the routine; ergo it had to be GLOBAL (_a_bad_thing_ (tm) in general as well) and that is not in the posted code... Well, if it is owing to Ulrich's hypothesis, it is so as a result of the function having side effects as noted before. That is not a wise design; at best it means you have to remember to not make certain assumptions about how you write code using the function and are you certain you know all the possible ramifications that could arise other than the one (accidentally, btw) found? I've already recommend two possible solutions that would avoid the problem. --
From: ralph on 1 Jul 2010 10:16 On Wed, 30 Jun 2010 22:25:58 +0200, Ulrich Korndoerfer <ulrich_wants_nospam(a)prosource.de> wrote: >Hi Karl, > >Karl E. Peterson schrieb: >> 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! >> > >Yes, that in general would be wise to avoid hazzles. In the case of the >OP CondB is a function call whose result delivers CondB *and* sets a >ByRef variable to a value on which the function call that delivers CondA >as result depends on. So she has to take measures that CondB is >evaluated first. > >Now CondA And CondB is just an expression, like 1 + 2 or CondA + CondB >or whatever. VB does not guarantee a certain sequence when evaluating >expressions, *except* when braces on subexpressions are used. Braces are >respected by VB and with braces one can control the sequence of >execution: braced subexpressions are evaluated as a whole. > >Unfortunately with CondA And CondB there is no subexpresssion one could >put braces around. But one could do tricks: > >CondA And (CondB And True) should result in CondB evaluated before CondA. Interesting that you kids keep talking about "VB" making some kind of ambiguous choice, or even more interesting that it sounds like you are suggesting that if VB had the ability to remove ambiguity - such problems could be avoided. ??? The programmer's intent is faithfully translated in the IDE and in a pcode release - "VB" itself appears to be sorting it out just fine. It is only when pcode is translated to C that a problem seems to occur. The advice is sound. It is only the target that is misplaced. Apparently VB *does* guarantee a certain sequence when evaluating expressions. A fact I find rather interesting. -ralph
From: dpb on 1 Jul 2010 10:26 ralph wrote: .... > The advice is sound. It is only the target that is misplaced. > Apparently VB *does* guarantee a certain sequence when evaluating > expressions. A fact I find rather interesting. I don't believe there's a "guarantee" in VB even in p-code since there is no published Standard to check conformance to. What you get is, therefore, by definition, what is guaranteed. It's not yet been shown precisely what the problem (if there is one) actually is unambiguously afaik. That would take as somebody noted, generating the code sequence of the actual code and looking at it and I've not bothered (nor am I going to) do so to determine precisely whether the hypothesis is the actual cause or not. Seems reasonable but there's still alternatives that could be going on in OP's code we've not seen. --
From: Nobody on 1 Jul 2010 10:44 "ralph" <nt_consulting64(a)yahoo.net> wrote in message news:sj6p261q7afievhdoahbn3euocosr66ggq(a)4ax.com... > Apparently VB *does* guarantee a certain sequence when evaluating > expressions. Yes, it's explained in MSDN. In MSDN Library Index, look for "And Operator", then click on "See Also", followed by "Operator Precedence". You may want to bookmark that page for future reference.
From: Daryl Muellenberg on 1 Jul 2010 11:17
"Claire" <replyto(a)fra> wrote in message news:Ofp6qZ#FLHA.1996(a)TK2MSFTNGP06.phx.gbl... > 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.",... > End If > End If > Just wanted to point out also that if rlineGetDevCaps(l) is False, then your message will not be displayed. You have to add another Else to match the first If in order to display your message if rlineGetDevCaps(l) is False. |