1. Linked win32lib structures
I've just about figured out how to read linked structures:
devmode=3Dfetch(psd,PAGESETUPDLG_pDevMode)
fetch( devmode, DEVMODE_dmOrientation ),
but initialising them has lost me. After:
psd =3D acquire_mem( 0, SIZEOF_PAGESETUPDLG )
devmode =3D acquire_mem ( 0, SIZEOF_DEVMODE )
store( devmode, DEVMODE_dmOrientation, 2 ) -- set to landscape
store( devmode, DEVMODE_dmPaperSize, 11 ) -- set to A5
I had hoped something vaguely like this would do:
store( psd, PAGESETUPDLG_pDevMode, devmode)=20
Everything I've tried, windows just quietly and firmly returns 0.=20
Pete
2. Re: Linked win32lib structures
>----- Original Message -----
>From: "Pete Lomax" <petelomax at blueyonder.co.uk>
>To: "EUforum" <EUforum at topica.com>
>Subject: Linked win32lib structures
>
>
>I've just about figured out how to read linked structures:
>
>devmode=fetch(psd,PAGESETUPDLG_pDevMode)
>omode = fetch( devmode, DEVMODE_dmOrientation ),
>
Yes, this is correct. The "pDevMode" fetch will get the address of the
DEVMODE structure. What happens is that the PAGESETUPDLG structure contains
a handle. A handle is the address of an address that points to the DEVMODE.
So if you fetch the "hDevMode" field, you get the address of the DEVMODE
structure's address.
>but initialising them has lost me. After:
>
>psd = acquire_mem( 0, SIZEOF_PAGESETUPDLG )
>devmode = acquire_mem ( 0, SIZEOF_DEVMODE )
>store( devmode, DEVMODE_dmOrientation, 2 ) -- set to landscape
>store( devmode, DEVMODE_dmPaperSize, 11 ) -- set to A5
>
>I had hoped something vaguely like this would do:
>store( psd, PAGESETUPDLG_pDevMode, devmode)
This should work too. The 'store' as written above, first grabs an address
to a 4-byte area and saves the 'devmode' value there, then stores that
address into the PAGESETUPDLG structure.
>Everything I've tried, windows just quietly and firmly returns 0.
When you say "windows...returns" what function are you calling to get that
return value?
--
cheers,
Derek Parnell
3. Re: Linked win32lib structures
- Posted by who at bellsouth.net
Jan 06, 2003
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
To All,
Ive yet to understand why all the overhead Win32lib has and I feel partly
responsible. When I sent Rob the the information that the .dll files werent
being released we assumed there was a memory leak in Euohoria or Win32lib.
I maybae dont understand why but why cant we just use get away with
the only draw back to this is sizeofStruct is not a given until all struct
defines
have their size.
struct_address = allocate(sizeofStruct)
mem_set(struct_address,0,sizeofStruct)
contant
dwplace1 = 0,
dwplace2 = 4,
dwplace3 = 8
now we know that sizeofStruct is 12
I dont see the need for the extra overhead is someone would convert the
"store"'d
values. This too would eliminate the need for "fetch" which is anoverhead
itself.
You'll probably come back with something like all data types arent the same.
yeah
like T_CHAR for example. I already know this much.
Not bitchin just asking,
Unknown
- ----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, January 06, 2003 4:25 PM
Subject: Re: Linked win32lib structures
>
> >----- Original Message -----
> >From: "Pete Lomax" <petelomax at blueyonder.co.uk>
> >To: "EUforum" <EUforum at topica.com>
> >Sent: Tuesday, January 07, 2003 4:08 AM
> >Subject: Linked win32lib structures
> >
>
> >I've just about figured out how to read linked structures:
> >
> >devmode=fetch(psd,PAGESETUPDLG_pDevMode)
> >omode = fetch( devmode, DEVMODE_dmOrientation ),
> >
>
> Yes, this is correct. The "pDevMode" fetch will get the address of the
> DEVMODE structure. What happens is that the PAGESETUPDLG structure contains
> a handle. A handle is the address of an address that points to the DEVMODE.
> So if you fetch the "hDevMode" field, you get the address of the DEVMODE
> structure's address.
>
> >but initialising them has lost me. After:
> >
> >psd = acquire_mem( 0, SIZEOF_PAGESETUPDLG )
> >devmode = acquire_mem ( 0, SIZEOF_DEVMODE )
> >store( devmode, DEVMODE_dmOrientation, 2 ) -- set to landscape
> >store( devmode, DEVMODE_dmPaperSize, 11 ) -- set to A5
> >
> >I had hoped something vaguely like this would do:
> >store( psd, PAGESETUPDLG_pDevMode, devmode)
>
> This should work too. The 'store' as written above, first grabs an address
> to a 4-byte area and saves the 'devmode' value there, then stores that
> address into the PAGESETUPDLG structure.
>
>
> >Everything I've tried, windows just quietly and firmly returns 0.
>
> When you say "windows...returns" what function are you calling to get that
> return value?
>
> --
> cheers,
> Derek Parnell
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
iQA/AwUBPhoSr8wfVotyflWYEQIvYQCgyANQN4Jm0roknhY1AdjSAjHrl4cAn3YI
tR8+Q9W5KbRDICX4r8BCumIl
=gu2C
-----END PGP SIGNATURE-----
4. Re: Linked win32lib structures
On Tue, 7 Jan 2003 08:25:51 +1100, Derek Parnell
<ddparnell at bigpond.com> wrote:
>>I've just about figured out how to read linked structures:
>>
>>devmode=3Dfetch(psd,PAGESETUPDLG_pDevMode)
>>fetch( devmode, DEVMODE_dmOrientation ),
>>
>
>Yes, this is correct.
Yeah, I figured/assumed that must be the right way, cos it works.
Thanks for confirming I'm on the right track
>The "pDevMode" fetch will get the address of the
>DEVMODE structure. What happens is that the PAGESETUPDLG structure =
contains
>a handle. A handle is the address of an address that points to the =
DEVMODE.
>So if you fetch the "hDevMode" field, you get the address of the DEVMODE
>structure's address.
>
>>but initialising them has lost me. After:
>>
>>psd =3D acquire_mem( 0, SIZEOF_PAGESETUPDLG )
>>devmode =3D acquire_mem ( 0, SIZEOF_DEVMODE )
>>store( devmode, DEVMODE_dmOrientation, 2 ) -- set to landscape
>>store( devmode, DEVMODE_dmPaperSize, 11 ) -- set to A5
>>
>>I had hoped something vaguely like this would do:
>>store( psd, PAGESETUPDLG_pDevMode, devmode)
>
>This should work too. The 'store' as written above, first grabs an =
address
>to a 4-byte area and saves the 'devmode' value there, then stores that
>address into the PAGESETUPDLG structure.
>
>
>>Everything I've tried, windows just quietly and firmly returns 0.
>
>When you say "windows...returns" what function are you calling to get =
that
>return value?
ok =3D w32Func( xPageSetupDlg, { psd } )
If I comment out that store( psd, PAGESETUPDLG_pDevMode, devmode),
the usual dialog pops up; when I put it back in, it just returns
false. No dialog, no usual wait, immediate return of 0.
I recon I'm putting a handle in a pointer or a pointer in a handle;
and topping it with not really knowing what I'm taking about 
I also tried (with same results) this:
>>store( psd, PAGESETUPDLG_hDevMode, devmode)
I suppose I should post my wrap of devmode(it is my very first attempt
at this afterall); maybe I just assume it is right because it returns
the right results, however there may be an obvious flaw in there:
typedef struct _devicemode { /* dvmd */ =20
TCHAR dmDeviceName[32];
WORD dmSpecVersion;
WORD dmDriverVersion;=20
WORD dmSize;
WORD dmDriverExtra;=20
DWORD dmFields;
short dmOrientation;
short dmPaperSize;
short dmPaperLength;
short dmPaperWidth;
short dmScale;
short dmCopies;
short dmDefaultSource;
short dmPrintQuality;
short dmColor;
short dmDuplex;
short dmYResolution;
short dmTTOption;
short dmCollate;
TCHAR dmFormName[32];
WORD dmUnusedPadding;
USHORT dmBitsPerPel;
DWORD dmPelsWidth;
DWORD dmPelsHeight;
DWORD dmDisplayFlags;
DWORD dmDisplayFrequency;
} DEVMODE;
DEVMODE_dmDeviceName =3D allot( {32,Byte} ),
DEVMODE_dmSpecVersion =3D allot( Word ),
DEVMODE_dmDriverVersion =3D allot( Word ),
DEVMODE_dmSize =3D allot( Word ), =20
DEVMODE_dmDriverExtra =3D allot( Word ),
DEVMODE_dmFields =3D allot( Long ),=09
DEVMODE_dmOrientation =3D allot( Word ),=09
DEVMODE_dmPaperSize =3D allot( Word ),
DEVMODE_dmPaperLength =3D allot( Word ),=09
DEVMODE_dmPaperWidth =3D allot( Word ), =20
DEVMODE_dmScale =3D allot( Word ),
DEVMODE_dmCopies =3D allot( Word ), =20
DEVMODE_dmDefaultSource =3D allot( Word ),
DEVMODE_dmPrintQuality =3D allot( Word ), =20
DEVMODE_dmColor =3D allot( Word ), =20
DEVMODE_dmDuplex =3D allot( Word ),
DEVMODE_dmYResolution =3D allot( Word ),=09
DEVMODE_dmTTOption =3D allot( Word ), =20
DEVMODE_dmCollate =3D allot( Word ),
DEVMODE_dmFormName =3D allot( {32,Byte} ),
DEVMODE_dmUnusedPadding =3D allot( Word ),
DEVMODE_dmBitsPerPel =3D allot( Word ), =20
DEVMODE_dmPelsWidth =3D allot( Long ), =20
DEVMODE_dmPelsHeight =3D allot( Long ),
DEVMODE_dmDisplayFlags =3D allot( Long ), =20
DEVMODE_dmDisplayFrequency =3D allot( Long ),
SIZEOF_DEVMODE =3D allotted_size(),
5. Re: Linked win32lib structures
On Mon, 6 Jan 2003 18:35:14 -0500, who at bellsouth.net wrote:
<snip>
> why cant we just use get away with
>
>the only draw back to this is
<snip, but no snip in the middle, honest>
PGP scrambled your message; please repost, thanks
Pete
6. Re: Linked win32lib structures
On Mon, 6 Jan 2003 18:35:14 -0500, who at bellsouth.net wrote:
>Ive yet to understand why all the overhead Win32lib has and I feel =
partly
>responsible.
See VB, Delphi, probably some others. Searching the web for info on
making a relatively minor mod to win32lib, I found far more rackloads
of vb/delphi/foxpro (just remembered another one) etc *GUNK* than you
obviously think. It really is not nice, but Euphoria is not alone.
I suppose if you code in C you just #include the massive .h header
files and be done with it, without thinking, so that doesn't count.
I suppose the cool thing would be for some kind soul to collect,
disseminate, analyse, wrap, and document all the C .h files and
functions in common use, ideally with a nice Euphoria front end.
Dang, isn't there something called win32lib which does that?
Pete
PS: this one, you really should see, I found particularly useful (Yes,
honestly, joking aside, I really did actually find it very useful). It
is for VB, and it begins with the wonderful comment:
"This seems too straight forward..."
http://p2p.wrox.com/archive/pro_vb/2002-05/9.asp
PPS: Do you really code all this out your head? Or do you have some
massive include files, at least for the constants? Or do you just not
use constants and instead look them up and hard-code their values?
7. Re: Linked win32lib structures
----- Original Message -----
From: <who at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Linked win32lib structures
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> To All,
>
> Ive yet to understand why all the overhead Win32lib has and I feel partly
> responsible. When I sent Rob the the information that the .dll files
werent
> being released we assumed there was a memory leak in Euohoria or Win32lib.
> I maybae dont understand why ...
The current routines involved with structures (RAM data mapping) are
designed to reduce errors in the library rather than cause the library to be
as fast as it possibly can be. Its just a matter of prioritites and
trade-offs.
> but why cant we just use get away with
>
> the only draw back to this is sizeofStruct is not a given until all struct
defines
> have their size.
> struct_address = allocate(sizeofStruct)
> mem_set(struct_address,0,sizeofStruct)
>
> contant
> dwplace1 = 0,
> dwplace2 = 4,
> dwplace3 = 8
>
> now we know that sizeofStruct is 12
Another drawback is the issue of reentrancy. If all the memory-mapped data
is allocated fixed locations for the duration of a program, we will have
problems when the same data area is used before the previous use is
completed. This can occur when a routine is invoked from itself, either
directly or indirectly, for example a WM_PAINT handler.
> I dont see the need for the extra overhead is someone would convert the
"store"'d
> values. This too would eliminate the need for "fetch" which is anoverhead
itself.
The "overhead" is always required. Its just a matter of when it is to be
done. Currently win32lib does the offset calculations and selection of the
correct variety of peek/poke at run time. To make the library a little
faster, this overhead could be done by the authors of the library at coding
time. The current method is less error prone than the proposed alternative.
> You'll probably come back with something like all data types arent the
same. yeah
> like T_CHAR for example. I already know this much.
Then you also know that the coder must select the correct offset, which is
dependant on all the data types prior to the field requested, and the
correct form of peek/poke, which is dependant on the size of the field
requested. Win32lib attempts to automate much of this process so as to
reduce mistakes by doing this work by hand.
> Not bitchin just asking,
just answering
--
Derek Parnell
8. Re: Linked win32lib structures
Where would I find your public key?
Lucius L. Hilley III
----- Original Message -----
From: <who at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Linked win32lib structures
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
<Snipped by me>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.8
>
> iQA/AwUBPhoSr8wfVotyflWYEQIvYQCgyANQN4Jm0roknhY1AdjSAjHrl4cAn3YI
> tR8+Q9W5KbRDICX4r8BCumIl
> =gu2C
> -----END PGP SIGNATURE-----
>
