IF does not Branch?

Started by IJRobson, June 16, 2014, 08:37:13 AM

Previous topic - Next topic

IJRobson

I have this Code within a UDF:

Code (winbatch) Select

   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) Select
If iFTPFileExist(conHandle, UserID, Filename) Then
with
Code (winbatch) Select
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) Select
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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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?
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

....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?
Regards,
....IFICantBYTE

Nothing sucks more than that moment during an argument when you realize you're wrong. :)

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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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?
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

Also a DebugTrace file of your script might be useful. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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

Quote from: IJRobson on June 17, 2014, 10:04:09 AM
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.

Quote
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.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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.     
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

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. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade