Difficulties with 'Line Input' ???

[norbert doerre]

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.

[Bob Zale]

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.

[Eddy Van Esch]

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

[Eddy Van Esch]

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

[norbert doerre]

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:

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!

[Bob Zale]

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.

[Richard Angell]

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.

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.

[Michael Mattias]

>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:

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

[norbert doerre]

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]

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.

[Michael Mattias]

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

[Eddy Van Esch]

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 ... :lam:

Another thing (that is not the cause of your problem) is that MS advises to ...

Kind regards

[norbert doerre]

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:

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