[fpc-devel] xshm.pp using ctypes
xshm.pp using ctypes attached
unit xshm;
interface
uses
ctypes,x,xlib;
{$ifndef os2}
{$LinkLib c}
{$LinkLib X11}
const
libX11='X11';
{$else}
const
libX11='X11';
{$endif}
{
Automatically converted by H2Pas 0.99.15 from xshm.h
The following command line parameters were used:
-p
-T
-S
-d
-c
xshm.h
}
{$PACKRECORDS C}
const
X_ShmQueryVersion = 0;
X_ShmAttach = 1;
X_ShmDetach = 2;
X_ShmPutImage = 3;
X_ShmGetImage = 4;
X_ShmCreatePixmap = 5;
ShmCompletion = 0;
ShmNumberEvents = ShmCompletion + 1;
BadShmSeg = 0;
ShmNumberErrors = BadShmSeg + 1;
type
PShmSeg = ^TShmSeg;
TShmSeg = culong;
PXShmCompletionEvent = ^TXShmCompletionEvent;
TXShmCompletionEvent = record
_type : cint;
serial : culong;
send_event : TBool;
display : PDisplay;
drawable : TDrawable;
major_code : cint;
minor_code : cint;
shmseg : TShmSeg;
offset : culong;
end;
PXShmSegmentInfo = ^TXShmSegmentInfo;
TXShmSegmentInfo = record
shmseg : TShmSeg;
shmid : cint;
shmaddr : Pchar;
readOnly : TBool;
end;
function XShmQueryExtension(para1:PDisplay):TBool;cdecl;external libX11;
function XShmGetEventBase(para1:PDisplay):cint;cdecl;external libX11;
function XShmQueryVersion(para1:PDisplay; para2:Pcint; para3:Pcint;
para4:PBool):TBool;cdecl;external libX11;
function XShmPixmapFormat(para1:PDisplay):cint;cdecl;external libX11;
function XShmAttach(para1:PDisplay;
para2:PXShmSegmentInfo):TStatus;cdecl;external libX11;
function XShmDetach(para1:PDisplay;
para2:PXShmSegmentInfo):TStatus;cdecl;external libX11;
function XShmPutImage(para1:PDisplay; para2:TDrawable; para3:TGC;
para4:PXImage; para5:cint;
para6:cint; para7:cint; para8:cint; para9:cuint; para10:cuint;
para11:TBool):TStatus;cdecl;external libX11;
function XShmGetImage(para1:PDisplay; para2:TDrawable; para3:PXImage;
para4:cint; para5:cint;
para6:culong):TStatus;cdecl;external libX11;
function XShmCreateImage(para1:PDisplay; para2:PVisual; para3:cuint;
para4:cint; para5:Pchar;
para6:PXShmSegmentInfo; para7:cuint;
para8:cuint):PXImage;cdecl;external libX11;
function XShmCreatePixmap(para1:PDisplay; para2:TDrawable; para3:Pchar;
para4:PXShmSegmentInfo; para5:cuint;
para6:cuint; para7:cuint):TPixmap;cdecl;external libX11;
implementation
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 reading
Uberto Barbini wrote: > Using natively utf-8 I think is impossible, because the encoding. Support might be implmemented like/in MBCS support. > Please note that at every Borland conference there is someone asking for > Unicode support since Delphi2... Not only for Delphi ;-) > There are several opensource library for managing unicode strings in delphi > but they are implemented as standard classes, not refcounted first class > citizen as long-string. It's not easy to find a solution suitable for everybody. There exist so many character encodings, a single class or data type hardly will cover all of them. Windows users may be happy with utf-16 (WideChar/WideString) because that's supported by the OS and some of its standard controls, but other OS have different models and support. As long as strings are created, used, and stored by an application, I'd suggest to use utf-8 for the external (disk file) representation, and WideString in the application. Then only two procedures are required to convert between utf-8 and WideString. Strings from other sources then have to be converted by the appropriate procedure into WideString, where the coder is responsible for the selection of the appropriate conversion; then a general library of such conversion procedures can be created and maintained for use in Pascal programs, or the coder can use his preferred opensource library. Some coders may prefer WideString also in disk files, if utf-8 files would be bigger in their natural or preferred language. Of course an application also can continue to use AnsiString instead of WideString, if Unicode support is not required. All these selections are up to the coder, the required data types and conversions are already supported. A compiler may support an Unicode switch, that maps the general data types Char and String into either AnsiChar/AnsiString or WideChar/WideString, in order to support easily portable code. The switch may be extended to map WideChar into utf-16, utf-32, utf-64, or whatever will become available in future compiler versions. A similar effect can be achieved by user-defined data types TChar and TString in portable code, with the possible problem that there exists no standard unit where these data types can be defined unambiguously, throughout whole projects. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RE: Hint: Parameter "sender" not used
Jeff Pohlmeyer wrote / napísal (a): This is not a big issue, anyway could we avoid the endless list of such similar hints compiling Lazarus and our program? I frequently find a similar annoyance with c library callbacks. For instance, most gtk functions have a "user_data" parameter that is often unused. Maybe there could be a procedure directive and/or compiler switch to ignore unsused parameter hints on prototyped functions, or perhaps to turn this particluar hint off completely? Or even a "dummy" function like: Ignore(Sender); - Jeff I agree. Something to turn of only parameter unused variables checks. It's not critical or anything but I think it might be good if it made it to 2.0 I'm not sure but doesn't Delphi actualy ignore unused parameters? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RE: Hint: Parameter "sender" not used
> This is not a big issue, anyway could we avoid the endless list > of such similar hints compiling Lazarus and our program? I frequently find a similar annoyance with c library callbacks. For instance, most gtk functions have a "user_data" parameter that is often unused. Maybe there could be a procedure directive and/or compiler switch to ignore unsused parameter hints on prototyped functions, or perhaps to turn this particluar hint off completely? Or even a "dummy" function like: Ignore(Sender); - Jeff -- __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
