Strange Behaviour

[Steve Bouffe]

The For Next loop (TL2) when TL1 = 1 get's executed twice displaying 2 message boxes reading "TL2= 1".

I Can see no reason why!

TS1 = DIR$( $DemoPlayerServerLocation + "MP3 Files\" + Item_ST + "_*.*" )

WHILE LEN( TS1 ) > 0
  TS2 = TS2 + TS1 + $CR
  TS1 = DIR$
WEND

TL1 = TALLY( TS2, $CR )

IF TL1 = 0 THEN
  MSGBOX "No Demo Files Exist", %MB_ICONERROR OR %MB_TASKMODAL, "Epos (PLA)"
ELSE

  REDIM GetListSelectArray_GL( 1 TO TL1, 1 TO 3 ) AS GLOBAL STRING

  FOR TL2 = 1 TO TL1

    MSGBOX "TL2=" + STR$( TL2 )
    CallBack_SR_String1_GL = PARSE$( TS2, $CR, TL2 )
    CallBack_SR_String2_GL = $DQ + PARSE$( CallBack_SR_String1_GL, "_", 1 ) + "_" + FORMAT$( TL2 ) + $DQ
    GetListSelectArray_GL( TL2, 1 ) = CallBack_SR_String1_GL
    GetListSelectArray_GL( TL2, 2 ) = PadString( UCASE$( RIGHT$( CallBack_SR_String1_GL, 3 )), 6 )

    TL3 = MCISENDSTRING( "open " + $DQ + $DemoPlayerServerLocation + "MP3 Files\" + CallBack_SR_String1_GL + $DQ + " alias " + CallBack_SR_String2_GL, "", 0, 0 )

    IF TL3 <> 0 THEN
      MSGBOX "Error " + FORMAT$( TL3 ) + " Opening File" + $CR + $CR + $DemoPlayerServerLocation + "MP3 Files\" + CallBack_SR_String1_GL, %MB_ICONERROR OR %MB_TASKMODAL, "Epos (PLA)"
    ELSE
      TL3 = MCISENDSTRING( "Status length " + CallBack_SR_String2_GL, szTimeFormat, BYVAL 256, 0 )
      IF TL3 <> 0 THEN
        MSGBOX "Error " + FORMAT$( TL3 ) + " Retrieving Media Length" + $CR + $CR + $DemoPlayerServerLocation + "MP3 Files\" + CallBack_SR_String1_GL, %MB_ICONERROR OR %MB_TASKMODAL, "Epos (PLA)"
      ELSE
        TL3 = CLNG( VAL( szTimeFormat )) \ 1000
        TS3 = LTRIM$( STR$( TL3 \ 60 ))
        GetListSelectArray_GL( TL2, 3 ) = TS3 + ":" + RIGHT$( TRIM$( STR$( 100 + ( TL3 MOD 60 ))), 2 )
      END IF
    END IF
    MCISENDSTRING "close " + CallBack_SR_String2_GL, "", 0, 0

  NEXT TL2

END IF

[Chris Holbrook]

I Can see no reason why!

I don't have a solution for you, but have you tried

• the debugger in the compiler
• commenting out bits of code until the problem goes away
• adding the style %MB_TASKMODAL and a title to your MSGBOX to make sure that it is truly arising from that piece of code, and that you can stop the app until you accept the message

[StanHelton]

I think Chris' suggestion is the best way to find the error. His suggestion to make the MSGBOX %TASK_MODAL is the first thing I would try, but I can't resist putting in my $0.02 worth.

What you have looks like it should run without an error. I can't get it to compile (not enough info provided) so here's my best 3 guesses.

In this line of code:

TL1 = TALLY( TS2, $CR )

Try using PARSECOUNT to determine the the number of elements:

 
TL1 = PARSECOUNT(TS2, $CR)

2nd guess:
You're accessing a remote site; is it possible you're not allowing for Unicode to ASCII conversion? Using $CR instead of $CRLF leads me to think this could be part of the problem.

My third guess, not knowing what your procedures are doing, would be that one of them is changing the value of TS2.

Stan

[Steve Bouffe]

OK It's taken me a while with the debugger as the program is 40,000 lines of source.

TL2 is a local variable so no other part of the procedure modifies it.

I did find that after this line is excuted, TL2 is reset to zero.

TL3 = MCISENDSTRING( "Status length " + CallBack_SR_String2_GL, szTimeFormat, BYVAL 256, 0 )

[Chris Holbrook]

Would help if you post the declarations too. For example, Is sztimeformat a pointer to a 256-byte buffer? because that is what mcisendstring is expecting... If sztimeformat is the buffer itself, BYVAL VARPTR ( sztimeformat) would do it, assuming sztimeformat is declared AS ASCIZ.

[Steve Bouffe]

LOCAL szTimeFormat AS ASCIIZ * 32

I just checked and some of the MP3 files are over 32 characters

I've expanded this to 1024 and the code runs without a problem.

Should this have affected the value of TL2?

[John Petty]

Looks like you created a classic buffer overflow vulnerabilty

[Chris Holbrook]

curse these fingers!

[Chris Holbrook]

Should this have affected the value of TL2?

well you told the function that it can trample on 256 bytes starting at whatever szbuffer gets resolved to. So do the decent thing and declare szbuffer as asciz * 256. Presumably some of the overflow coincides with TL2, and who knows what else.

[Kev Peel]

The buffer is passed correctly, but the buffer size wasn't. Use sizeof(szTimeFormat) instead of a fixed (incorrect) number and that will avoid problems like this.