Luca Politti | 1 Jun 14:41 2007
Picon

free library problem

Hi group!!!

I'm coming with another ctypes problem... :)

I've created a my own dll ( I'm feeling very important!! :) ) and now I
want to load it from Python. So I've done this:

 >>> import ctypes as C
 >>> C.windll.LoadLibrary("cti.dll")

the loading is ok...

Now I want to "unload" this library because my C ide can't compile the dll
until the library is free, so I call:

 >>> C.windll.FreeLibrary(l)

but this error is raised( :( ):

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Sviluppo\python2.4\lib\site-packages\ctypes\__init__.py", 
line 390, in __getattr__
    dll = self._dlltype(name)
  File "C:\Sviluppo\python2.4\lib\site-packages\ctypes\__init__.py", 
line 315, in __init__
    self._handle = _dlopen(self._name, mode)
WindowsError: [Errno 126] Can't find the specified module

What could it be? Can you help me please?
(Continue reading)

Lenard Lindstrom | 1 Jun 17:57 2007
Picon

Re: free library problem

Luca Politti wrote:
> Hi group!!!
>
> I'm coming with another ctypes problem... :)
>
> I've created a my own dll ( I'm feeling very important!! :) ) and now I
> want to load it from Python. So I've done this:
>
>  >>> import ctypes as C
>  >>> C.windll.LoadLibrary("cti.dll")
>
> the loading is ok...
>
> Now I want to "unload" this library because my C ide can't compile the dll
> until the library is free, so I call:
>
>  >>> C.windll.FreeLibrary(l)
>
> but this error is raised( :( ):
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "C:\Sviluppo\python2.4\lib\site-packages\ctypes\__init__.py", 
> line 390, in __getattr__
>     dll = self._dlltype(name)
>   File "C:\Sviluppo\python2.4\lib\site-packages\ctypes\__init__.py", 
> line 315, in __init__
>     self._handle = _dlopen(self._name, mode)
> WindowsError: [Errno 126] Can't find the specified module
>
(Continue reading)

Corey Staten | 3 Jun 00:47 2007
Picon

Screen Capture to Bitmap

I'm having trouble doing a screen capture to a bitmap using ctypes.  Here's the code:


from ctypes import *

class Bitmap(Structure):
    _fields_ = [("bitmapType", c_long),
                ("width", c_long),
                ("height", c_long),
                ("widthBytes", c_long),
                ("planes", c_short),
                ("bitsPerPixel", c_short)
                ("data", POINTER(c_ulong))]


if __name__ == "__main__":
    user32 = WinDLL("user32.dll")
    gdi32 = WinDLL("gdi32.dll")
   
    #Constants
    SM_CXSCREEN = 0
    SM_CYSCREEN = 1
    SRCCOPY = 0xCC0020
   
    #Capture the Bitmap
    width = user32.GetSystemMetrics(SM_CXSCREEN)
    height = user32.GetSystemMetrics(SM_CYSCREEN)
    screenDC = user32.GetWindowDC(user32.GetDesktopWindow())
    captureDC = gdi32.CreateCompatibleDC(screenDC)
    captureBitmap = gdi32.CreateCompatibleBitmap(screenDC, width, height)
    gdi32.SelectObject(captureDC, captureBitmap)
    gdi32.BitBlt(captureDC, 0, 0, width, height, screenDC, 0, 0, SRCCOPY)

    picture = Bitmap()
    gdi32.GetObjectA( captureBitmap, 24, byref(picture))


None of the functions are returning errors, and the resulting Bitmap structure has the correct width/height/etc, but the "data" field is a NULL pointer.  I have no idea why, any help is appreciated.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
ctypes-users mailing list
ctypes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ctypes-users
Lenard Lindstrom | 3 Jun 06:20 2007
Picon

Re: Screen Capture to Bitmap

Corey Staten wrote:
> I'm having trouble doing a screen capture to a bitmap using ctypes.  
> Here's the code:
>
>
> from ctypes import *
>
> class Bitmap(Structure):
>     _fields_ = [("bitmapType", c_long),
>                 ("width", c_long),
>                 ("height", c_long),
>                 ("widthBytes", c_long),
>                 ("planes", c_short),
>                 ("bitsPerPixel", c_short)
>                 ("data", POINTER(c_ulong))]
>
>
> if __name__ == "__main__":
>     user32 = WinDLL("user32.dll")
>     gdi32 = WinDLL("gdi32.dll")
>    
>     #Constants
>     SM_CXSCREEN = 0
>     SM_CYSCREEN = 1
>     SRCCOPY = 0xCC0020
>    
>     #Capture the Bitmap
>     width = user32.GetSystemMetrics(SM_CXSCREEN)
>     height = user32.GetSystemMetrics(SM_CYSCREEN)
>     screenDC = user32.GetWindowDC(user32.GetDesktopWindow())
>     captureDC = gdi32.CreateCompatibleDC(screenDC)
>     captureBitmap = gdi32.CreateCompatibleBitmap(screenDC, width, height)
>     gdi32.SelectObject(captureDC, captureBitmap)
>     gdi32.BitBlt(captureDC, 0, 0, width, height, screenDC, 0, 0, SRCCOPY)
>
>     picture = Bitmap()
>     gdi32.GetObjectA( captureBitmap, 24, byref(picture))
>
>
> None of the functions are returning errors, and the resulting Bitmap 
> structure has the correct width/height/etc, but the "data" field is a 
> NULL pointer.  I have no idea why, any help is appreciated.
>   

You must allocate the integer array for the data pointer of the BITMAP 
structure. GetObject doesn't it for you.

--

-- 
Lenard Lindstrom
<len-l <at> telus.net>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Simon Burton | 5 Jun 01:49 2007

Re: Problems with 64 signed integer

On Fri, 24 Nov 2006 18:35:27 +0100
Thomas Heller <theller <at> ctypes.org> wrote:

> 
> I can reproduce this bug :-(.
> 
> >     My questions are:
> >        - is this intended for c_longlong to be only 4 bytes in some 
> > cases ? (in ISO C99, my understanding was that long long was guaranteed 
> > to be at least 8 bytes)
> 
> Of course not.  c_longlong should have the same size as the struct module's
> 'q' specifier.
> 
> >        - is the lack of c_int64 of bug of ctypes, libffi, both ?
> >        - I try to understand where the problem lies, but I don't have 
> > much knowledge on python C Api, so I am a bit lost in the code of ctypes
> 
> I've seen that you already answered that yourself in the bug you
> submitted to ubuntu - looks like a libffi bug.
> 
> I will add some testcases to ctypes so that this problem will at
> least be seen in the ctypes unittests.

I'm having the same problem, probably for the same reasons.
What exactly is the solution ? Build libffi from source ?

thanks,

Simon.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Thomas Heller | 6 Jun 08:11 2007

Re: Problems with 64 signed integer

Simon Burton schrieb:
> On Fri, 24 Nov 2006 18:35:27 +0100
> Thomas Heller <theller <at> ctypes.org> wrote:
> 
>> 
>> I can reproduce this bug :-(.
>> 
>> >     My questions are:
>> >        - is this intended for c_longlong to be only 4 bytes in some 
>> > cases ? (in ISO C99, my understanding was that long long was guaranteed 
>> > to be at least 8 bytes)
>> 
>> Of course not.  c_longlong should have the same size as the struct module's
>> 'q' specifier.
>> 
>> >        - is the lack of c_int64 of bug of ctypes, libffi, both ?
>> >        - I try to understand where the problem lies, but I don't have 
>> > much knowledge on python C Api, so I am a bit lost in the code of ctypes
>> 
>> I've seen that you already answered that yourself in the bug you
>> submitted to ubuntu - looks like a libffi bug.
>> 
>> I will add some testcases to ctypes so that this problem will at
>> least be seen in the ctypes unittests.
> 
> I'm having the same problem, probably for the same reasons.
> What exactly is the solution ? Build libffi from source ?

No need to rebuild libffi - ctypes has its own libffi sources included.
You should be able to build ctypes from sources if you use the tarball
on the sourceforge download area.

Thomas

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Luis Solis | 6 Jun 23:17 2007
Picon

calling a fortran dll from python

Hi!

I'm using ctypes to call a fortran dll from python. I have no problems passing arguments of integer or double types, both scalars or arrays, single or double precission, but I have errors with python strings.

For example:

....
ap = windll.LoadLibrary(locationDll)

mychar=c_char_p('0123456789')
ap.TEST_02(mychar) #error

the message error is
ValueError: Procedure probably called with not enough arguments (4 bytes missing)

______________

fortran code (CVF compiler).

subroutine TEST_02(a)
...!DEC$ ATTRIBUTES DLLEXPORT :: TEST_02
...CHARACTER(10):: a
...open(31,file='pru.txt ')
...write(31,*) a
...close(31)
...return
END subroutine


Also I tried with
ap.TEST_02(byref(mychar)) and the message error is the same

I post this problem to comp.lang.python and comp.lang.fortran with no results



--
Luis Solís
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
ctypes-users mailing list
ctypes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ctypes-users
Mowry, Peter | 7 Jun 01:28 2007
I am using ctypes to control a computer hardware simulation via a single
shared library entry point, but having trouble getting it to fully load
all the .so files on Linux :-(

ctypes directly loads my entry point ".so" shared library:
self.mainentrylib = ctypes.CDLL(strPathAbs, mode=ctypes.RTLD_GLOBAL) #
load main entry point
# I don't know why I have to use RTLD_GLOBAL, but when I do 60 / 63 work

Then I call an exported function on self.mainentrylib, which causes the
entry point shared library to load a bunch of model pieces (from the C++
code) (from a "libs" dir).  On Windows, all 63 pieces (".dll" files)
load without problem.  On Linux, only 60 of the 63 pieces (".so" files)
load, and 3 of them give me an error trying to load.

I modified the C++ code (of the main entry point shared library) to
print GetLastError(), which reported 2, which translates via strerror(2)
to "No such file or directory".  But this error message can't be true
b/c the file does exist (and it's in the same dir as the other 60).

I didn't think anything was special about these 3 shared libraries, but
something must be.  Anyone run into something similar or have any ideas?

Any responses appreciated; thanks!

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG <at> python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Ralph Reinhold | 7 Jun 01:58 2007
Picon
Picon

Re: calling a fortran dll from python

Been there, done that.  Fortran only passes by reference.  You have to 
treat the variable like a pointer.

Ralph
Luis Solis wrote:
> Hi!
>
> I'm using ctypes to call a fortran dll from python. I have no problems 
> passing arguments of integer or double types, both scalars or arrays, 
> single or double precission, but I have errors with python strings.
>
> For example:
>
> ....
> ap = windll.LoadLibrary(locationDll)
>
> mychar=c_char_p('0123456789')
> ap.TEST_02(mychar) #error
>
> the message error is
> ValueError: Procedure probably called with not enough arguments (4 
> bytes missing)
>
> ______________
>
> fortran code (CVF compiler).
>
> subroutine TEST_02(a)
> ...!DEC$ ATTRIBUTES DLLEXPORT :: TEST_02
> ...CHARACTER(10):: a
> ...open(31,file='pru.txt ')
> ...write(31,*) a
> ...close(31)
> ...return
> END subroutine
>
>
> Also I tried with
> ap.TEST_02(byref(mychar)) and the message error is the same
>
> I post this problem to comp.lang.python and comp.lang.fortran with no 
> results
>
>
>
> -- 
> Luis SolĂ­s
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> ctypes-users mailing list
> ctypes-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ctypes-users
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Lenard Lindstrom | 7 Jun 02:11 2007
Picon

Re: calling a fortran dll from python

Luis Solis wrote:
> Hi!
>
> I'm using ctypes to call a fortran dll from python. I have no problems 
> passing arguments of integer or double types, both scalars or arrays, 
> single or double precission, but I have errors with python strings.
>
> For example:
>
> ....
> ap = windll.LoadLibrary(locationDll)
>
> mychar=c_char_p('0123456789')
> ap.TEST_02(mychar) #error
>
> the message error is
> ValueError: Procedure probably called with not enough arguments (4 
> bytes missing)
>
> ______________
>
> fortran code (CVF compiler).
>
> subroutine TEST_02(a)
> ...!DEC$ ATTRIBUTES DLLEXPORT :: TEST_02
> ...CHARACTER(10):: a
> ...open(31,file='pru.txt ')
> ...write(31,*) a
> ...close(31)
> ...return
> END subroutine
>
>
> Also I tried with
> ap.TEST_02(byref(mychar)) and the message error is the same
>
> I post this problem to comp.lang.python and comp.lang.fortran with no 
> results
>
This has come up before. If you are using g77 then I believe exported 
functions have a C calling convension.

--

-- 
Lenard Lindstrom
<len-l <at> telus.net>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Gmane