Am 25.09.2012 23:16, schrieb Henry Vermaak:
On 25 September 2012 20:57, Christo wrote:
Any ideas on how to define the calling convention in the import unit so
that it is either stdcall or cdecl depending on the target OS?
I've used a macro for this in the past. E.g. :
{$macro on}
{$ifdef wi
2012/9/25 Bernd :
> 2012/9/25 patspiper :
>> procedure test;
>> begin
>> Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1);
>> end;
>
> and if you cast it to some other pointer type before dereferencing the
> error goes away:
>
> procedure test;
> begin
> Move(MyClass1.Ref.Data^, PByte(MyClass2.R
On 25 September 2012 20:57, Christo wrote:
> Any ideas on how to define the calling convention in the import unit so
> that it is either stdcall or cdecl depending on the target OS?
I've used a macro for this in the past. E.g. :
{$macro on}
{$ifdef windows}
{$define CCONV:=stdcall}
{$else}
Hi!
Am Dienstag, den 25.09.2012, 21:57 +0200 schrieb Christo:
> On Sun, 2012-09-23 at 23:26 +0200, Johann Glaser wrote:
> > Hi!
> >
> > Some time ago somebody asked about USB support. I've now finished the
> > libusb 1.0 header translation and object-oriented wrapper.
>
> Hi Hansi,
>
> I see th
>
> I have not seen any evidence that it has ever been used other than for CSV,
> but I may be wrong. So I suspect that this should be acceptable.
>
>
>From a simple and unexperienced user point of view, the many times I
used the SDF dataset were only to load a CSV into a TMemDataset or
similar fo
On Sun, 2012-09-23 at 23:26 +0200, Johann Glaser wrote:
> Hi!
>
> Some time ago somebody asked about USB support. I've now finished the
> libusb 1.0 header translation and object-oriented wrapper.
Hi Hansi,
I see that the imported functions in libusb.pas are declared with the
cdecl calling conve
On Tue, 2012-09-25 at 09:41 +0100, Graeme Geldenhuys wrote:
> then do...
>
> cd pas-libusb
> git checkout libusb-1.0
Thanks Graeme (and Henry). Obviously I'm new to git and tried commands
similar to svn which didn't work quite as expected.
Regards,
Christo
_
On 25/09/12 20:43, Bernd wrote:
2012/9/25 patspiper :
procedure test;
begin
Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1);
end;
and if you cast it to some other pointer type before dereferencing the
error goes away:
procedure test;
begin
Move(MyClass1.Ref.Data^, PByte(MyClass2.Ref.Data
On 25 Sep 2012, at 20:15, Bernd wrote:
> I know that git is not as complicated
Please move this discussion to fpc-other, thanks.
Jonas
FPC mailing lists admin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mai
2012/9/25 Graeme Geldenhuys :
> Thanks for the tip, but Git is *not* difficult to use. To cover the average
> developer workflow, you need like 3-4 commands max. If you can't remember 4
> commands, then you have bigger issues than git.
I know that git is not as complicated as it initially seems b
2012/9/25 patspiper :
> procedure test;
> begin
> Move(MyClass1.Ref.Data^, MyClass2.Ref.Data^, 1);
> end;
and if you cast it to some other pointer type before dereferencing the
error goes away:
procedure test;
begin
Move(MyClass1.Ref.Data^, PByte(MyClass2.Ref.Data)^, 1);
end;
But this should
2012/9/25 patspiper :
> Hi,
>
> Despite
> http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields,
> shouldn't the following be legal? I tested under FPC 2.6.1 and 2.7.1.
This shouldn't even matter here since IMHO it should work even if Ref
were a function
On 2012-09-25 17:22, Bernd wrote:
I highly recommend using the easygit wrapper to make life easier,
especially when you come from SVN because git will be very confusing
Thanks for the tip, but Git is *not* difficult to use. To cover the
average developer workflow, you need like 3-4 commands
2012/9/24 Christo :
> I'm new to using git so it may be
> something trivial I'm missing.
Regarding git,
I highly recommend using the easygit wrapper to make life easier,
especially when you come from SVN because git will be very confusing
in the beginning if you are used to svn and then try to u
Hi!
Am Dienstag, den 25.09.2012, 09:41 +0100 schrieb Graeme Geldenhuys:
> On 2012-09-24 14:39, Christo wrote:
> > I'm interested in testing your wrapper. Unfortunately I cannot clone
> > the git link above, I get an error (fatal:
> > https://github.com/hansiglaser/pas-libusb/tree/libusb-1.0/info/
Hi,
Despite
http://wiki.freepascal.org/User_Changes_2.4.0#Treating_direct-mapped_properties_as_regular_fields,
shouldn't the following be legal? I tested under FPC 2.6.1 and 2.7.1.
TMyRecord = record
Data: pointer;
end;
TMyClass = class
private
FRef: TMyRecord;
public
p
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 25-9-2012 10:11, michael.vancann...@wisa.be wrote:
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 18:43, Michael Van Canneyt wrote:
On Mon, 24 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 17:22,
michael.vancanneyt-0is9kj9s
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 25-9-2012 10:16, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
I'd suggest:
1. adding a readme as indicated in my other mail so that users and
developers do not fall into the same trap
On 25-9-2012 10:16, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
> On Tue, 25 Sep 2012, Reinier Olislagers wrote:
>> I'd suggest:
>> 1. adding a readme as indicated in my other mail so that users and
>> developers do not fall into the same trap
>
> Hoho, there is no trap :-)
Well, not in
On 25-9-2012 10:11, michael.vancann...@wisa.be wrote:
> On Tue, 25 Sep 2012, Reinier Olislagers wrote:
>> On 24-9-2012 18:43, Michael Van Canneyt wrote:
>> On Mon, 24 Sep 2012, Reinier Olislagers wrote:
>>>
On 24-9-2012 17:22,
michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.g
On 2012-09-24 14:39, Christo wrote:
I'm interested in testing your wrapper. Unfortunately I cannot clone
the git link above, I get an error (fatal:
https://github.com/hansiglaser/pas-libusb/tree/libusb-1.0/info/refs not
That was a web link, not the git url. If you followed that link with
you
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
That is indeed another approach that doesn't require specs nor docs.
Unfortunately only available to those that have the keys to kingdom :)
Well, I think that trying to let TSDFDataset conform to certain "SDF"
specs is trying to do some unjustifi
On Tue, 25 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 18:43, Michael Van Canneyt wrote:
On Mon, 24 Sep 2012, Reinier Olislagers wrote:
On 24-9-2012 17:22,
michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org
wrote:
On Mon, 24 Sep 2012, Reinier Olislagers wrote:
On 25-9-2012 7:44, Reinier Olislagers wrote:
> On 24-9-2012 20:21, Michael Van Canneyt wrote:
>> IMHO, it should do fixed format and CSV as indicated by the RFC I posted.
>> All the rest is nice, but not required from my perspective.
> It's not required anymore from my perspective either. I just
On 24-9-2012 20:21, Michael Van Canneyt wrote:
> On Mon, 24 Sep 2012, Ludo Brands wrote:
That is in contradiction with the existing implementation
>>> as well as
the following comments following comments in SDFData.pp
14/Ago/01 Version 2.00 (Orlando Arrocha)
J
Am 25.09.2012 07:56, schrieb Reinier Olislagers:
On 24-9-2012 21:08, Sven Barth wrote:
On 24.09.2012 21:06, Sven Barth wrote:
Do you think this version is good enough? Comments here or on the forum
would be welcome.
The only problem I have with TSDFDataset is the following issue related
to mo
26 matches
Mail list logo
