From: L D Blake <[EMAIL PROTECTED]>
Organization: Secret society to end secret societies
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal]About order of units...
Send reply to: [EMAI
In reply to your message of August 31, 2003
> I have one idea (although I'm no windows programmer). How do you play
> sound files - using some kind of your own code, or relying on default
> Windows handlers (i.e. installed Windows codecs)? If it's the latter,
> you might be possibly using IE for
From: L D Blake <[EMAIL PROTECTED]>
Organization: Secret society to end secret societies
To: Michalis Kamburelis <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal]About order of units...
Send reply to: [EMAIL PROTECTE
In reply to your message of August 31, 2003
> At least some of the range check errors are due to errors in the
> Windows unit (mingling cardinals=dwords and longints). However, these
> are not errors that will change the course of your program in any way,
> as the data passed around doesn't chang
> h2pas is only a helper program that does the major part of C header
> translation. It uses longint by default as parameter type for
> macro's. When you want to have correct macro's you need to create/edit
> them manualy.
Yep... I know. But it occurs to me that whoever did the conversion didn't
From: L D Blake <[EMAIL PROTECTED]>
Organization: Secret society to end secret societies
To: Marco van de Voort <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal]About order of units...
Send reply to: [EMAIL PROTECTE
In reply to your message of August 31, 2003
> If you have a look at the implementation, you'll quickly find, that
> all of the examples you listed in this mail make absolutely _no_
> difference.
It DOES matter, especially in structures where windows is accessing things as
an offset from a point
In reply to your message of August 31, 2003
>>Yep... I know. But it occurs to me that whoever did the conversion didn't
>>check very carefully.
> When the windows unit was created it was more important to get the compiler
> running correct natively under windows. After that nobody took care of
L D Blake wrote:
In reply to your message of August 31, 2003
If you have a look at the implementation, you'll quickly find, that
all of the examples you listed in this mail make absolutely _no_
difference.
It DOES matter, especially in structures where windows is accessing things as
an offse
In reply to your message of August 31, 2003
> I simply think you're on
> a bad track suspecting that your problems are originated from some bugs
> in Windows unit.
Ok, I can accept that... but now I'm left to wonder what is causing all those
bizarre range checking errors and why my project's scr
On zondag, aug 31, 2003, at 20:40 Europe/Brussels, L D Blake wrote:
Ok, I can accept that... but now I'm left to wonder what is causing
all those
bizarre range checking errors
At least some of the range check errors are due to errors in the
Windows unit (mingling cardinals=dwords and longints).
In reply to your message of August 30, 2003
> h2pas is only a helper program that does the major part of C header
> translation. It uses longint by default as parameter type for
> macro's. When you want to have correct macro's you need to create/edit
> them manualy.
Yep... I know. But it occ
>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and
LONGWORD
>> types...
> Can you name examples of that?
A little more information ... I just ran h2pas on a couple of header files
from the SDK... It
In reply to your message of August 30, 2003
>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
>> types...
> Can you name examples of that?
A little more information ... I just ran h2pas o
In reply to your message of August 30, 2003
>> The real problem here is types declared in the windows unit where, as I
>> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
>> types...
> Can you name examples of that?
> Most notably about byte's and word's confusion
> The real problem here is types declared in the windows unit where, as I
> pointed out previously, LongInt has been confused with BYTE, WORD and LONGWORD
> types...
Can you name examples of that?
Most notably about byte's and word's confusion (so places where types
have a different size then th
intead they will co-exist in one namespace. However, this is not
implemented in FPC 1.0.x so if you use only FPC 1.0.x there's nothing to
worry (however you should be aware of this if you're writing some
non-testing code, that you might want to compile some day with FPC 1.1 or
higher).
FPC 1.1
In reply to your message of August 30, 2003
> Yes. Identifiers in Windows unit will be hidden by same identifiers in
> WinFix unit.
Ok... I was pretty sure that would work. And as you point out so well I'm
aware that it's stopgap at best.
The real problem here is types declared in the windows u
L D Blake wrote:
> Ok, still messing with this silly problem...
>
> Now the question is about order of declaration in units...
>
> Lets say I wrote a unit "WinFix" with some of these cursed range checking
> problems cleaned up... am I correct in assuming that if I added it to my units
> list lik
Ok, still messing with this silly problem...
Now the question is about order of declaration in units...
Lets say I wrote a unit "WinFix" with some of these cursed range checking
problems cleaned up... am I correct in assuming that if I added it to my units
list like this:
Uses
20 matches
Mail list logo
