Announcement

Collapse
No announcement yet.

Difficulties with 'Line Input' ???

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Difficulties with 'Line Input' ???

    I've a problem (with PBWin 8.0.4 ??) I never noticed before reading from a simple text file within a simple DLL. Following code is part of a function called within the 'process attach' event of LibMain:

    '...
    local sTemp as string

    Open "TEXTFILE.TXT" For Input As #1
    Line Input #1, sTemp
    Close #1
    '...

    Executing "Line Input #1, sTemp" leads to error 477.

    Syntax error - Something is incorrect on the line; however, the compiler could not determine a proper error message or decode the line further.

    A common cause is mixing two statement keywords together, using a reserved keyword for a variable name, or attempting to use an undefined COM INTERFACE member (in an OBJECT statement) when using early-binding, etc.

    It seems I'm currently not able to figure that out.
    Norbert Doerre

  • #2
    I think there's some serious confusion here. Error number 477 is not a run-time error, so it's not possible it occurs from execution of a line of code.

    It only occurs during compilation. When it's reported, the compiler also displays the line number and approximate column number where your syntax error was detected. Use those numbers to locate the position of the error in your source code.

    If you still have a problem, please post the specified line of code along with the reported column number.

    Best regards,

    Bob Zale
    PowerBASIC Inc.

    Comment


    • #3
      Norbert,

      That code snippet is compiling and running fine here (PBWin 8.04).
      I am not running it from a dll, but simply from PBMAIN and it does what it is supposed to do .

      Maybe there are some invisible control characters on that line of code ?
      Try erasing the offending line and retyping it .

      Another thing (that is not the cause of your problem) is that MS advises to run as little code as possible from within LibMains 'process attach' because the dll might not be properly initialised yet.
      I will look for a reference about this.

      Kind regards
      Last edited by Eddy Van Esch; 1 Nov 2007, 04:36 AM.
      Eddy

      Comment


      • #4
        Norbert,

        Here is that specific 'warning' from MSDN that I was referring to.

        Warning On attach, the body of your DLL entry-point function should perform only simple initialization tasks, such as setting up thread local storage (TLS), creating synchronization objects, and opening files. You must not call LoadLibrary in the entry-point function, because you may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, you must not call the FreeLibrary function in the entry-point function on detach, because this can result in a DLL being used after the system has executed its termination code.
        Calling Win32 functions other than TLS, synchronization, and file functions may result in problems that are difficult to diagnose. For example, calling User, Shell, COM, RPC, and Windows Sockets functions (or any functions that call these functions) can cause access violation errors, because their DLLs call LoadLibrary to load other system components.
        To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. Otherwise, you can have the initialization routine create a named mutex, and have each routine in the DLL call the initialization routine if the mutex does not exist.
        Kind regards
        Eddy

        Comment


        • #5
          The compilation error code detailed

          My project situation here is always hard to organize the way to send all the code, because there exist too many dependencies from other project parts.

          In this case, it's "only" an error during the compilation process of one single DLL.
          The DLL is a standard DLL containing a standard LibMain; here the original code:
          Code:
          Function LibMain (ByVal hInstance As Long, ByVal fwdReason As Long, ByVal lpvReserved As Long) As Long
              Select Case fwdReason
          	Case %DLL_PROCESS_ATTACH
          		ghInstance = hInstance
          		SetWheelScript() ' <--- this is the only function to be called
          		Function = 1
          	Case %DLL_PROCESS_DETACH
          		Function = 1
          	Case %DLL_THREAD_ATTACH
          		Function = 1
          	Case %DLL_THREAD_DETACH
          		Function = 1
             End Select
          End Function
          
          'And here is the function itself:
          
          Sub SetWheelScript()
             Local sCmdExt As String
             Local tfFound As Integer
             Local sTemp As String
             Open "CMDMacro.def" For Input As #1
          	Line Input #1, sTemp  '<--- Line with compiler error 477
          '  	While IsFalse Eof(1)     
          '		Line Input #hFile, sTemp     
          '		If InStr(1, sTemp, lcase("w1;")) Then
          '			tfFound = 1
          '			Exit Loop
          '		End If  
          '	Wend            
          '       If tfFound = 0 Then
          '      	        MsgBox "Nicht gefunden"
          '       End If
             Close #1
          '
          '   The script write code is omitted, because I have first to read the file.
          '
          End Sub
          The rest of the source code only contains some irrelevant functions, and,
          above all, with the faulty line commented out, the DLL is running very well.
          The lines above were commented out to be able to better locate the error.


          Here the log file:

          PowerBASIC for Windows
          PB/Win Version 8.04
          Copyright (c) 1996-2007 PowerBasic Inc.
          Venice, Florida USA
          All Rights Reserved

          Error 477 in C:\DOKUME~1\ndoerre\EIGENE~1\Projekte\MECHAN~1\PB_MCA~1\Wheel\mdWheel.bas(287:024): Syntax error
          Line 287: Line Input #1, sTemp

          I did all to eliminate the bug, edited the syntax again. In Germany, we have a holyday today which (in fact my family) hinders me to try out all the other file read statements. But I will be able to do it tonight. By the way, I never use Vista, but XP Prof!
          Norbert Doerre

          Comment


          • #6
            The code snippet you posted above compiles just fine as it is. I think your best bet would be to zip up some source code which actually generates this error and email it to [email protected] They'll give you an explanation of the issue.

            Thanks!

            Bob Zale
            PowerBASIC Inc.

            Comment


            • #7
              SInce we do not have all the code it is only possible to see a couple of problems.

              First, the post you did make disagrees with itself in that there is a reference to #1 and #hFile, yet it is not clear if you're trying to read 2 files or only one as the code suggests. If as the altered sub below shows, it is only one file handle, #hFile, then another error is uncovered. Might try correcting it to see what happens as well.

              The line in your code:

              If InStr(1, sTemp, lcase("w1;")) Then

              is not correct for PB. PB requires lcase to be lcase$.

              Here's a revised sub that works by falling through to the tfFound = 0 test, since I tried it without a "CMDMacro.def" present.

              Code:
              SUB SetWheelScript()
                 LOCAL sCmdExt AS STRING
                 LOCAL tfFound AS INTEGER
                 LOCAL sTemp AS STRING
                 LOCAL hFile AS LONG
                 hFile = FREEFILE
                 OPEN "CMDMacro.def" FOR INPUT AS #hFile
                 LINE INPUT #hFile, sTemp  '<--- Line with compiler error 477
                 WHILE ISFALSE EOF(hFile)
                     LINE INPUT #hFile, sTemp
                     IF INSTR(1, sTemp, LCASE$("w1;")) THEN
                         tfFound = 1
                         EXIT LOOP
                     END IF
                 WEND
                 IF tfFound = 0 THEN
                       MSGBOX "Nicht gefunden"
                 END IF
                 CLOSE #1
               END SUB
              This corrected function errors out in a regular .bas. However, since you have a dependancy on the "CMDMacro.def" being present, you might want to check to see if it is present and accounted for in the current directory(?) before attempting to open it. That way you can bail out before trying to open it in the case it is not there.
              Last edited by Richard Angell; 1 Nov 2007, 07:50 AM.
              Rick Angell

              Comment


              • #8
                >SetWheelScript() ' <--- this is the only function to be called [in DLL_PROCESS_ATTACH]

                That function 'breaks the rules' re what may be executed on DLL_PROCESS_ATTACH because the string operations in that function use OLEAUT32.DLL.

                Functions executed on DLL_PROCESS_ATTACH should be those in KERNEL32.DLL only.

                You will probably 'get away with it' since the compiler puts OLEAUT32 into the import table ahead of any DECLAREd externals, so it's probably loaded before your library, but it's still a bad habit... after all, Windows may some day decide to 'optimize' the load order and not necessarily load in the same order as the import table. I doubt that will happen, but why tempt fate?

                If you want to see what system DLLs are ALWAYS imported by your PB programs, write this program:
                Code:
                FUNCTION PBMAIN () AS LONG
                  FUNCTION = 1
                END FUNCTION
                Compile. Then use this...
                Show exports and imports for PB/Win 6x, 7x (original by Torsten Reinow)
                ... to generate a list of imports and exports.

                Since none of your application code uses ANYTHING, whatever imported libraries appear are those always added by the compiler.

                MCM
                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Thank You all very much for Your kind engagement!!!

                  Michael, the problem I have here might be also dependent from my current computer configuration.
                  The MS API is a vivid language, and if You are not in detail reported about the changements they made, then You run sometimes into these traps. As I told above, I never experienced that kind of bug all the years before. So I asked myself what it could have been caused by. As Bob tells the code is compilable on his computer.
                  So, I rather think that there might be in fact some new 'dependencies' created by MS lib files. It wouldn't be the first time.
                  I compiled the code without the string operations which I commented out to avoid additional conflicts. I'm not shure if the PB compiler uses OLEAUT32.DLL for reading from file.
                  I'll send a report as soon as I'll find the detailed cause of the error.
                  Norbert Doerre

                  Comment


                  • #10
                    Eddy,
                    I'm aware of the MS instructions to code sequences inside LibMain. So I already commented out the lines with string operations. But until now, it ran fine for about 6 years or so. The error is caused by the Line Input command and refers to the string variable "sTemp". This is confusing me.
                    But I do my best to find the real cause.
                    Norbert Doerre

                    Comment


                    • #11
                      As Mr. Zale pointed out, your Error 477 has nothing to do with LibMain/DLL_PROCESS_ATTACH handling. Since 477 is a compile-time error, your program file was never compiled and therefore your progam file never executed.

                      No, I don't know how 'compile-time error 477' drifted into a review of LibMain processing, but drift it did.

                      MCM
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        Originally posted by Michael Mattias View Post
                        No, I don't know how 'compile-time error 477' drifted into a review of LibMain processing,
                        Fortunately I do. I mentioned it as a side note (but maybe I am already regretting it ... :yawn2: :lam:

                        Another thing (that is not the cause of your problem) is that MS advises to ...
                        Kind regards
                        Last edited by Eddy Van Esch; 1 Nov 2007, 05:24 PM.
                        Eddy

                        Comment


                        • #13
                          I got it running!!!

                          After some frustrating hours of experimenting with my code and running always into the same situation as shown in Eddy's animated gif in his last comment I went to sleep and woke up this morning like Phoenix from the ashes, copy/pasted the LibMain function to a new DLL project, compiled it and - again the compiler did not accept it. :-(
                          Then I tried to forget Eddy's blue eye animation and rewrote the whole LibMain code from scratch and started the compiler again.....
                          Bingo, compilation is successful.
                          As Bob (thanks forever!) mentioned there existed in fact an unvisible copy/paste problem inside my libMain standard code snippet.

                          So, following code in fact runs:
                          Code:
                          Function LibMain (ByVal hInstance As Long, ByVal fwdReason As Long, ByVal lpvReserved As Long) As Long
                          	Select Case fwdReason
                          		Case %DLL_PROCESS_ATTACH
                          			ghInstance = hInstance
                          			'Sample with registry write:
                          			RegSetString(%HKEY_CURRENT_USER, "Software\Test", "Test", "Test")
                                                  'Sample with File I/O
                          			Local stemp As String
                          			Open "cmdext.def" For Input As #1
                          			Line Input #1, stemp
                          			Close #1
                          			Function = 1
                          		Case %DLL_PROCESS_DETACH
                          			Function = 1
                          		Case %DLL_THREAD_ATTACH
                          			Function = 1
                          		Case %DLL_THREAD_DETACH
                          			Function = 1
                          	End Select
                          End Function
                          Last edited by norbert doerre; 2 Nov 2007, 08:01 AM. Reason: Phoenix instead of Poenix
                          Norbert Doerre

                          Comment

                          Working...
                          X