Hi Przemek,
I have read your post, but I have not understood how I can use your code
passing structures between prg and c code and viceversa.
Could you kindly post an example, also of a simple structure ?
understood.
Now I'm trying to generalize it, if it is possible.
Best regards,
Frances
Hi Przemek,
Il 05/02/2009 2.50, Przemyslaw Czerpak ha scritto:
Passing C structures as string is also bad idea.
If we do not need support for direct updating C structure
members at .prg level then it will be enough to introduce
special type of GC pointer to hold all such structures with
basic t
Przemek
Przemyslaw Czerpak-2 wrote:
>
> Passing C structures as string is also bad idea.
> If we do not need support for direct updating C structure
> members at .prg level then it will be enough to introduce
> special type of GC pointer to hold all such structures with
> basic type veryficatio
Il 05/02/2009 15.43, Viktor Szakáts ha scritto:
as possible WINAPI interface. If in doubt I'd personally in all
cases prefer to favour the "Harbour feel". "Harbour feel" means
that .prg programmer shouldn't be able to cause a GPF/memory
corruption using .prg level
>
> as possible WINAPI interface. If in doubt I'd personally in all cases
>> prefer to favour the "Harbour feel". "Harbour feel" means that .prg
>> programmer shouldn't be able to cause a GPF/memory corruption using .prg
>> level WINAPI calls.
>>
>> This is ok for me, just to decide if we have to
Il 05/02/2009 15.17, Viktor Szakáts ha scritto:
Thanks for clarifying, I still agree with you.
Thank you
If you ask me, I'd rather fully ignore the explicitly passed
length parameter, as the only result of that is potential
buffer overrun and big security holes (and/or more complicated
an
>
> the name I proposed is related to MSDN syntax and to ms libs.
> To be clear in MSDN function:
> CreateCompatibleDC() is defined:
>
> Requirements
> Windows NT/2000/XP/Vista: Included in Windows NT 3.1 and later.
> Windows 95/98/Me: Included in Windows 95 and later.
> Header: Declared in Wing
Hi Pritpal, Viktor,
Il 05/02/2009 0.58, Pritpal Bedi ha scritto:
Hi
wapi_gdi32.c OR wapi_gdi.c ( removing 32, may contain gdi32 or gdi++
functions )
the name I proposed is related to MSDN syntax and to ms libs.
To be clear in MSDN function:
CreateCompatibleDC() is defined:
Requirements
W
On Wed, 04 Feb 2009, Pritpal Bedi wrote:
Hi Pritpal
> HB_FUNC( WAPI_PRINTDLG )
> {
>PRINTDLG *pd = hb_parc( 1 ); // structure WHEREEVER possible
>...
>wapi_retstruct( pd );
> }
Passing C structures as string is also bad idea.
If we do not need support for direct updating C structure
>
> hbwapi.h
> ===
> #define wapi_parwparam( n ) ( ( WPARAM ) ( HB_PTRDIFF ) hb_parnint( n ) )
> #define wapi_parlparam( n ) ( ( LPARAM ) ( HB_PTRDIFF ) hb_parnint( n ) )
> #define wapi_parhandle( n ) ( ( HANDLE ) ( HB_PTRDIFF ) hb_parnint( n ) )
> #define wapi_parhwnd( n )( ( HWND )
Hi
wapi_gdi32.c OR wapi_gdi.c ( removing 32, may contain gdi32 or gdi++
functions )
hbwapi.h
===
#define wapi_parwparam( n ) ( ( WPARAM ) ( HB_PTRDIFF ) hb_parnint( n ) )
#define wapi_parlparam( n ) ( ( LPARAM ) ( HB_PTRDIFF ) hb_parnint( n ) )
#define wapi_parhandle( n ) ( ( HANDLE )
Okay, we're on the same page.
Maybe "wapi_" is the most convenient and a good
middle ground between w_ and winapi_. My vote goes
for this one, but it's not a very strong preference.
More opinions? Pritpal?
Brgds,
Viktor
On Wed, Feb 4, 2009 at 10:20 PM, Francesco Saverio Giudice <
i...@fsgiudice.
Il 04/02/2009 10.45, Viktor Szakáts ha scritto:
Ok for using *.ch, *.h, but if it is possible, to see immediately
where put a new addition, as per c api file I would like to mantain
ms naming convention, so for me it will be better to use, f.e.,
w_winuser.ch or winuserapi.ch
W
>
>
>> Ok for using *.ch, *.h, but if it is possible, to see immediately where
> put a new addition, as per c api file I would like to mantain ms naming
> convention, so for me it will be better to use, f.e., w_winuser.ch or
> winuserapi.ch
We can do this. I personally prefer "w_winuser.ch".
Or
Hi Viktor,
Il 04/02/2009 10.14, Viktor Szakáts ha scritto:
In contrary, I'm happy you've joined the thread :)
Thanks
2) using, as above, header defines in *.api files (winuser.api,
wingdi.api)
Here I don't agree, because usually I find it better
to use standard extensions, so if s
Hi Viktor,
Il 04/02/2009 10.14, Viktor Szakáts ha scritto:
In contrary, I'm happy you've joined the thread :)
Thanks
2) using, as above, header defines in *.api files (winuser.api,
wingdi.api)
Here I don't agree, because usually I find it better
to use standard extensions, so if s
On Wed, Feb 4, 2009 at 9:51 AM, Massimo Belgrano wrote:
>
> http://apps.sourceforge.net/mediawiki/harbour-project/index.php?title=Main_Page
> I am logged as mbelgrano but i not found any way add page
Indeed, rights have to be given, or somehow editing must be
set to be unrestricted, but couldn't
Hi Francesco, Pritpal,
5) Further cleanup hbwin.lib (naming, better separation of API, additional
>> convenience functions and classes).
>> 6) Remove hbwhat.lib altogether.
>>
>>
> sorry to jump in and probably missing some infos, but only as suggestion
> may I propose to adopt this naming conve
Hi Viktor, Pritpal,
Il 04/02/2009 3.35, Viktor Szakáts ha scritto:
To put it shortly: IMO hbwin should be a pure wrapper for
the Windows API and closely Windows API related features,
nothing more, nothing less. It's also important that
64-bit, Unicode and GCC/MSVC/POCC/OW compatibility be
k
http://apps.sourceforge.net/mediawiki/harbour-project/index.php?title=Main_Page
I am logged as mbelgrano but i not found any way add page
2009/2/4 Viktor Szakáts :
>> Rule as this are important (also if not jet approved)
>> How give importance to this info?
>> How we can know this rule to future h
>
> Rule as this are important (also if not jet approved)
> How give importance to this info?
> How we can know this rule to future harbour developer without reading
> all messages post in mailing list
> can restructure doc with information for harbour prg level user from
> harbour c level develop
Rule as this are important (also if not jet approved)
How give importance to this info?
How we can know this rule to future harbour developer without reading
all messages post in mailing list
can restructure doc with information for harbour prg level user from
harbour c level developer?
Can adopt
>
> Now the another guideline:
>
> Many functions of WINAPI accept structures as their
> parameters. Should we use them to be compatible with
> WINAPI exactly or should we use arrays?
> Both approaches have merits and demerits.
> I personally propose to use STRUCTURES where ever
> possible. What gr
Wich disadvantaage using structure ?
http://api.farmanager.com/en/winapi/index.html
2009/2/4 Pritpal Bedi :
> Many functions of WINAPI accept structures as their
> parameters. Should we use them to be compatible with
> WINAPI exactly or should we use arrays?
> Both approaches have merits and dem
Viktor
>I fully endorse your idea. In Harbour we seem to
>like these kind of clean things :)
Clearly visible fact.
<<<
One problem with the clean approach is that the
Windows API is huge and there is really nobody
interested in maintaining a full set of wrappers.
This is huge work and most ppl
Hi Pritpal,
> Again I say I agree with your view point.
>
> Long back, perhaps 2002, I initiated a lot of
> message about this very fact, on xHarbour NG,
> to streamline all WINAPI functionality in one
> common library. At that moment What32 was
> just came into being. I was puzzled and
> wondere
Viktor
Again I say I agree with your view point.
Long back, perhaps 2002, I initiated a lot of
message about this very fact, on xHarbour NG,
to streamline all WINAPI functionality in one
common library. At that moment What32 was
just came into being. I was puzzled and
wondered why everyone is
>
> I agree with your viewpoint but at the moment, or until
> we create a common library to be used by all libs, I would like
> if you change WIN_ * with something else.
>
> Perhaps I cannot change my whole code as I use hbwin.lib also.
You can continue to use latest version which doesn't
have th
Viktor
Viktor Szakáts wrote:
>
> IMO these needs to be changed in GTWVG, hbwin is the
> generic lib in this case. F.e. my local framework lib uses
> prefix_win_*() naming to avoid such possible collisions,
> similar should be used for GTWVG and for all contribs
> implementing local Windows API
Hi Pritpal,
> vszakats wrote:
> >
> > * Renaming hbwin lib functions to a common and bitwidth-neutral
> > namespace, which is WIN_*():
> > - W32_REGPATHSPLIT()-> WIN_REGPATHSPLIT()
> >
>
> WIN_ namespace is in use in GTWVG, and probably it
> will class with these chang
Hi Viktor
Pritpal Bedi wrote:
>
> WIN_ namespace is in use in GTWVG, and probably it
> will class with these changes.
>
And many functions are clashing.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10164--trunk-harbour-tp2182
Hi Viktor
vszakats wrote:
>
> * Renaming hbwin lib functions to a common and bitwidth-neutral
> namespace, which is WIN_*():
> - W32_REGPATHSPLIT()-> WIN_REGPATHSPLIT()
>
WIN_ namespace is in use in GTWVG, and probably it
will class with these changes.
Regards
Pr
Revision: 10164
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10164&view=rev
Author: vszakats
Date: 2009-02-03 23:31:56 + (Tue, 03 Feb 2009)
Log Message:
---
2009-02-04 00:29 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbwin/win_reg.prg
33 matches
Mail list logo
