Bug maybe? This doesn't work. 
Author Message
 Bug maybe? This doesn't work.

Yes i did understood that.
Just wanted to point out that i need this functionality and i'm afraid
PBMain will/might take over in future releases.


Wed, 03 Sep 2003 05:35:11 GMT  
 Bug maybe? This doesn't work.
Lance,

Should i be afraid that future releases might allways set Libmain to 1 ?
When i make use of my custom added Libmain, on incorrect load/initialize i
return 0.
The DLL is no longer loaded.
I really need this feature.



Wed, 03 Sep 2003 02:49:16 GMT  
 Bug maybe? This doesn't work.
I think he mean't only 1 is returned if the LIBMAIN is not found
during compile time.  If you have a custom LIBMAIN yours will be
executed.  That's what I read.

On Fri, 16 Mar 2001 19:49:16 +0100, "E.B. Knoppert(NL)"

Quote:

>Lance,

>Should i be afraid that future releases might allways set Libmain to 1 ?
>When i make use of my custom added Libmain, on incorrect load/initialize i
>return 0.
>The DLL is no longer loaded.
>I really need this feature.



Wed, 03 Sep 2003 04:15:26 GMT  
 Bug maybe? This doesn't work.
I think your are using VB?
VB uses unicode, i think you need a conversion to byte arrays
Btw, in this case Libmain doesn't do anything, you could remove it.
WEP is useless, it's for 16bit DLL's

Retest this code using a PB exe, this should work.
And you don't need the array counter, use Ubound for that.

Quote:

>When I run the code below, the Init populates the Tables array of user
>type TableType correctly.

>But the Open routine doesn't display the correct information when
>accessing the same array again.  The strings seems to 'run' into each
>other.

>However, removing the two LONGs from TableType works.  Any
>suggestions?  I think this is a bug.  Code seems simple enough to me.

>----------------------------------------------------------

>#REGISTER ALL
>#COMPILE DLL
>#DIM ALL
>#INCLUDE "WIN32API.INC"
>#INCLUDE "VBAPI32.INC"

>TYPE TableType
>  TableName    as String * 70
>  FileName     as String * 8
>  LKFileHandle as Long
>  OVFileHandle as Long
>END TYPE

>Global Tables() as TableType
>Global TotalTables as Long

>FUNCTION LibMain(BYVAL hInstance AS LONG, BYVAL fwdReason AS LONG,
>BYVAL lpvReserved AS LONG) EXPORT AS LONG
>  SELECT CASE fwdReason
>    CASE %DLL_PROCESS_ATTACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_PROCESS_DETACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_THREAD_ATTACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_THREAD_DETACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>  END SELECT
>END FUNCTION

>FUNCTION rvInit () EXPORT AS INTEGER
>  Dim Temp as Long
>  TotalTables = 0
>  FOR Temp = 1 to 5
>      INCR TotalTables
>      ReDim Preserve Tables(1 TO TotalTables)
>      Tables(TotalTables).TableName = "TABLE " + str$(TotalTables)
>      Tables(TotalTables).FileName = "BLAH"
>      Tables(TotalTables).LKFileHandle = 0
>      Tables(TotalTables).OVFileHandle = 0

>      msgbox Tables(TotalTables).TableName, , "DEBUG"
>  NEXT

>  rvInit = -1 ' success
>END FUNCTION

>FUNCTION rvOpen () EXPORT AS INTEGER
>  Dim ThisTable as Long
>  For ThisTable = 1 to TotalTables
>     msgbox Tables(ThisTable).TableName, , "DEBUG"
>  Next

>  rvOpen = -1  'success

>END FUNCTION

>FUNCTION Wep (BYVAL nParameter AS INTEGER) EXPORT AS WORD
>  Wep = 1   ' success
>END FUNCTION



Tue, 02 Sep 2003 16:53:01 GMT  
 Bug maybe? This doesn't work.
When I run the code below, the Init populates the Tables array of user
type TableType correctly.

But the Open routine doesn't display the correct information when
accessing the same array again.  The strings seems to 'run' into each
other.

However, removing the two LONGs from TableType works.  Any
suggestions?  I think this is a bug.  Code seems simple enough to me.

----------------------------------------------------------

#REGISTER ALL
#COMPILE DLL
#DIM ALL
#INCLUDE "WIN32API.INC"
#INCLUDE "VBAPI32.INC"

TYPE TableType
  TableName    as String * 70
  FileName     as String * 8
  LKFileHandle as Long
  OVFileHandle as Long
END TYPE

Global Tables() as TableType
Global TotalTables as Long

FUNCTION LibMain(BYVAL hInstance AS LONG, BYVAL fwdReason AS LONG,
BYVAL lpvReserved AS LONG) EXPORT AS LONG
  SELECT CASE fwdReason
    CASE %DLL_PROCESS_ATTACH
       LibMain = 1   'success!
      EXIT FUNCTION
    CASE %DLL_PROCESS_DETACH
       LibMain = 1   'success!
      EXIT FUNCTION
    CASE %DLL_THREAD_ATTACH
       LibMain = 1   'success!
      EXIT FUNCTION
    CASE %DLL_THREAD_DETACH
       LibMain = 1   'success!
      EXIT FUNCTION
  END SELECT
END FUNCTION

FUNCTION rvInit () EXPORT AS INTEGER
  Dim Temp as Long
  TotalTables = 0
  FOR Temp = 1 to 5
      INCR TotalTables
      ReDim Preserve Tables(1 TO TotalTables)
      Tables(TotalTables).TableName = "TABLE " + str$(TotalTables)
      Tables(TotalTables).FileName = "BLAH"
      Tables(TotalTables).LKFileHandle = 0
      Tables(TotalTables).OVFileHandle = 0

      msgbox Tables(TotalTables).TableName, , "DEBUG"
  NEXT

  rvInit = -1 ' success
END FUNCTION

FUNCTION rvOpen () EXPORT AS INTEGER
  Dim ThisTable as Long
  For ThisTable = 1 to TotalTables
     msgbox Tables(ThisTable).TableName, , "DEBUG"
  Next

  rvOpen = -1  'success

END FUNCTION

FUNCTION Wep (BYVAL nParameter AS INTEGER) EXPORT AS WORD
  Wep = 1   ' success
END FUNCTION



Tue, 02 Sep 2003 15:37:02 GMT  
 Bug maybe? This doesn't work.
I modified your code into an EXE (deleted LIBMAIN, added a PBMAIN,
removed WEP).  In PBMAIN I called rvInit followed by rvOpen and I do
not see any "mangled" data.

BTW, the WEP function is not used by 32-bit windows... you can safely
delete that function completely!  Also, since your LIBMAIN is only
returning non-zero for all 'fdwReason' values, you can omit the
function completely, since PB/DLL will automatically add a LIBMAIN to
the DLL that returns non-zero.

I also note that you are returning the function values as 16-bit
integers... if you are calling this code from VB, are you declaring
the functions to use 16-bit variables too?  In Win32, it is much
faster and more efficient to use 32-bit LONG integers, even in your VB
code.

Here is the EXE version of your code, and this works fine for me...
does this work for you too?  If so, this tends to indicate that the
problem is with the VB declaration or calling of the two functions,
rvInit and rvOpen.

#COMPILE EXE
#REGISTER ALL
#DIM ALL

TYPE TableType
  TableName    AS STRING * 70
  FileName     AS STRING * 8
  LKFileHandle AS LONG
  OVFileHandle AS LONG
END TYPE

GLOBAL Tables() AS TableType
GLOBAL TotalTables AS LONG

FUNCTION rvInit () EXPORT AS INTEGER
  DIM Temp AS LONG
  TotalTables = 0
  FOR Temp = 1 TO 5
      INCR TotalTables
      REDIM PRESERVE Tables(1 TO TotalTables) AS GLOBAL tabletype
      Tables(TotalTables).TableName = "TABLE " + STR$(TotalTables)
      Tables(TotalTables).FileName = "BLAH"
      Tables(TotalTables).LKFileHandle = 0
      Tables(TotalTables).OVFileHandle = 0
      MSGBOX Tables(TotalTables).TableName, , "rvInit"
  NEXT
  rvInit = -1 ' success
END FUNCTION

FUNCTION rvOpen () EXPORT AS INTEGER
  DIM ThisTable AS LONG
  FOR ThisTable = 1 TO TotalTables
     MSGBOX Tables(ThisTable).TableName, , "rvOpen"
  NEXT
  rvOpen = -1  'success
END FUNCTION

FUNCTION PBMAIN
    rvinit
    rvopen
END FUNCTION

I hope this helps!

Quote:

>When I run the code below, the Init populates the Tables array of user
>type TableType correctly.

>But the Open routine doesn't display the correct information when
>accessing the same array again.  The strings seems to 'run' into each
>other.

>However, removing the two LONGs from TableType works.  Any
>suggestions?  I think this is a bug.  Code seems simple enough to me.

>----------------------------------------------------------

>#REGISTER ALL
>#COMPILE DLL
>#DIM ALL
>#INCLUDE "WIN32API.INC"
>#INCLUDE "VBAPI32.INC"

>TYPE TableType
>  TableName    as String * 70
>  FileName     as String * 8
>  LKFileHandle as Long
>  OVFileHandle as Long
>END TYPE

>Global Tables() as TableType
>Global TotalTables as Long

>FUNCTION LibMain(BYVAL hInstance AS LONG, BYVAL fwdReason AS LONG,
>BYVAL lpvReserved AS LONG) EXPORT AS LONG
>  SELECT CASE fwdReason
>    CASE %DLL_PROCESS_ATTACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_PROCESS_DETACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_THREAD_ATTACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>    CASE %DLL_THREAD_DETACH
>       LibMain = 1   'success!
>      EXIT FUNCTION
>  END SELECT
>END FUNCTION

>FUNCTION rvInit () EXPORT AS INTEGER
>  Dim Temp as Long
>  TotalTables = 0
>  FOR Temp = 1 to 5
>      INCR TotalTables
>      ReDim Preserve Tables(1 TO TotalTables)
>      Tables(TotalTables).TableName = "TABLE " + str$(TotalTables)
>      Tables(TotalTables).FileName = "BLAH"
>      Tables(TotalTables).LKFileHandle = 0
>      Tables(TotalTables).OVFileHandle = 0

>      msgbox Tables(TotalTables).TableName, , "DEBUG"
>  NEXT

>  rvInit = -1 ' success
>END FUNCTION

>FUNCTION rvOpen () EXPORT AS INTEGER
>  Dim ThisTable as Long
>  For ThisTable = 1 to TotalTables
>     msgbox Tables(ThisTable).TableName, , "DEBUG"
>  Next

>  rvOpen = -1  'success

>END FUNCTION

>FUNCTION Wep (BYVAL nParameter AS INTEGER) EXPORT AS WORD
>  Wep = 1   ' success
>END FUNCTION

Lance
powerbasic Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Tue, 02 Sep 2003 21:30:06 GMT  
 Bug maybe? This doesn't work.
Edwin, he is 100% correct.

Quote:

>I think he mean't only 1 is returned if the LIBMAIN is not found
>during compile time.  If you have a custom LIBMAIN yours will be
>executed.  That's what I read.

>On Fri, 16 Mar 2001 19:49:16 +0100, "E.B. Knoppert(NL)"

>>Lance,

>>Should i be afraid that future releases might allways set Libmain to 1 ?
>>When i make use of my custom added Libmain, on incorrect load/initialize i
>>return 0.
>>The DLL is no longer loaded.
>>I really need this feature.

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Thu, 04 Sep 2003 13:27:30 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. BLT installs but doesn't work, and TkTable doesn't build

2. BUG stipple doesn't work for ovals

3. BUG? exec $editor $file doesn't work

4. EAI works (or doesn't work) differently under different platforms

5. tkman works/doesn't work [hpux9]

6. match works, don't match doesn't

7. Bevel Buttons' icon doesn't work

8. re.LOCALE | re.IGNORECASE doesn't work as you'd expect

9. expect's full_buffer doesn't seem to work

10. [entry]'s -disabledforeground doesn't work

11. += doesn't work in python cgi's

12. tkdesk on fedora core 5 -- doesn't run, doesn't compile

 

 
Powered by phpBB® Forum Software