IF does not Branch?

[IJRobson]

I have this Code within a UDF:

Code: Winbatch

   For A = 1 to ItemCount(Selected, @Tab)
      Item = ItemExtract(A, Selected, @Tab)
      Filename = StrTrim(ItemExtract(1, Item, "|"))
      Size = StrTrim(ItemExtract(2, Item, "|"))
      LogAPI(Handle, LogFile, "Accessing: %FileName% (%Size% Bytes)")

      If iFTPFileExist(conHandle, UserID, Filename) Then
          Message(A, "TRUE")
      Else
          Message(A, "FALSE")
      Endif

      Message(A, "Loop")
   Next A
 

When I run it Message Boxes appear as Follows:
      1 TRUE
      1 FALSE
      1 LOOP
      2 TRUE
      2 FALSE
      2 LOOP

This implies the IF is running both the TRUE and FALSE conditions?

[IJRobson]

Want ever the Problem is it relates to iFTPFileExist?

If I replace

Code: Winbatch

If iFTPFileExist(conHandle, UserID, Filename) Then

with

Code: Winbatch

If @True Then

The output is:
   1 TRUE
   1 LOOP
   2 TRUE
   2 LOOP

Which is correct!

[IJRobson]

As a workaround I have changed the code to this which only enters either the TRUE or FALSE Branch:

Code: Winbatch

                For A = 1 to ItemCount(Selected, @Tab)
                        Item = ItemExtract(A, Selected, @Tab)
                        Filename = StrTrim(ItemExtract(1, Item, "|"))
                        Size = StrTrim(ItemExtract(2, Item, "|"))
                        LogAPI(Handle, LogFile, "Accessing: %FileName% (%Size% Bytes)")

                        FileFound =  iFTPFileExist(conHandle, UserID, FileName)

                        If FileFound Then
                                Message(A, "TRUE")
                        Else
                                Message(A, "FALSE")
                        Endif

                        Message(A, "Loop")
                Next A
 

[td]

The only known cause of the behavior you describe is some kind of process stack corruption.  However, we are unable to reproduce the problem.

[IJRobson]

Understood, well the workaround to assign the returned value to a variable and then use the Variable in the IF statement is working fine so I will not worry about it.

Thanks for the information.

[td]

You wouldn't be using (or better misusing) Intcontrol 73 in your UDF by chance?

[....IFICantBYTE]

Not sure if this has something to do with the way your first version was being interpreted, but having a "Then" after your "If" and evaluated expression, kind of implies a single statement if..then..else with no EndIf necessary.

In other words, I would remove the "Then" at the end of the If line altogether,
OR, replace that whole line with something like "If iFTPFileExist(conHandle, UserID, Filename) == @TRUE"
OR, put the whole thing into a single statement IF with the message for the TRUE condition on the same line directly after the "Then" statement and only put the "Else" and its message  on the next line with no EndIf statement at all.

Maybe the WB interpreter is being confused by the syntax and being in a loop?.... See if it works then?

[td]

The WIL interpreter knowns enough to ignore the 'then' when it is part of a structured 'if'. If the rest of the script is written correctly, all the 'then' does is cause some extra typing and waste a few CPU cycles.

[IJRobson]

TD,

I am not using IntControl 73 so that is not the problem.

I have run the code with and without the "Then" and get the same results.

I have also found that other Branches within the code are not doing what I expect and ShellExecute does not work whenever I use the iFTPFileExist within my code.  If I don't use this function then everything else works fine?

So I guess the problem is Process Stack Corruption related and the iFTPFileExist just pushes it over the edge?

I am in the process of rewriting (optimizing) the code around this call to try and determine what could be the problem.

Any recommendations for managing the Stack?  i.e. If I convert code into UDFs will this make any difference to the Stack usage, chances of finding the cause?

Thanks

[td]

If the cause is indeed stack corruption, there is not much you as a WinBatch user can do about it because it is likely a bug in the the implementation of iFTPFileExist or one of the win32 APIs the function calls.  Stack corruption problems also have a habit of showing up in unpredictable ways because they are influenced by the state of the process stack when the machine instructions causing the corruption are executed. 

Which version of Windows, WinBatch, and Wininet extender are you using?

[td]

Also a DebugTrace file of your script might be useful. 

[IJRobson]

OK, Understood.

I am using WinBatch 2014A (Compiler) with the Latest updates of the Extenders as listed in VCheck.wbt.

Whatever the cause assigning the return value of iFTPFileExist to a Variable and then using this Variable in the IF statement definitely has an effect.

Some of the other (unrelated) IF statements that did not function as expected work if I only used the return Value in the IF statement and not the Actual Function itself, FileExist() being one example.

[IJRobson]

My current code is working fine so a debugtrace is unlikely to provide any information you can't get yourself.

Also the UDF that showed the problem also contains a lot of Company related information which wound be difficult to sanitize for posting.

Sorry.

[td]

My current code is working fine so a debugtrace is unlikely to provide any information you can't get yourself.

Not true. The DebugTrace might be very useful, since you seem to be the only one with the problem.

Also the UDF that showed the problem also contains a lot of Company related information which wound be difficult to sanitize for posting.

Ctrl+h can often make quick work of unwanted information without rendering the result unenlightening.

[IJRobson]

OK, I have attached a DebugTrace output.

I have removed the 500K of Spaces (always created?) at the beginning of the file and XXXXXXXXXX out some company text / information.

[td]

A DebugTrace file of the failing version would have been more useful but this one does add one more hypothetical cause to the list.  Unfortunately, none of the hypothetical causes can be tested because the problem cannot be reproduced. 

A dump of the simplest script that causes the problem as you have described it,  would be useful.  Also, if you have a 64-bit system, you could compile the failing version as a 64-bit executable and test it.  If it does not fail as a 64-bit exe, it would explain a lot.     

[IJRobson]

The DebugTrace is from the latest version of the application that I originally reported the problem with but in the last three days this has been effectively been rewritten to resolve the problem.

I don't have a copy of the Script from when I originally raised this issue.  The Sample Example was cut from this application but this code does not exist in this form in the new version so I can't drop this code back in to the new Version.

All this came from the original post "iFTPFileSize Error 300: FileOpen failed when Firewall active?" and the subsequent posting about the existence of the originally undocumented iFTPFileExist routine.

I am in the process of changing other applications to use iFTPFileExist so if any of these show signs of this problem I will upload a TraceDebug.

I am running on a 32 Bit Machine running XP so I can't help with the 64-bit version.

Thanks for your help anyway.

[td]

We appreciate your efforts.