I don't have Delphi 2010 yet and not sure if I'll sit this version out or not,
since I'm quite happy with D2009 so I haven't had a chance to play with it yet.
Here's a great blog post on it:
http://robstechcorner.blogspot.com/2009/09/delphi-2010-rtti-basics.html
Has there been any discussion
Thanks, Martin -- I'm doing the if/then, and am being reminded of what
typecasting actually does!
On Fri 23 Oct 2009, Martin wrote:
> A type cast does not changes the value. A typecast merely allows you
> to store a value into a field of a different type
On Sat, Oct 24, 2009 at 3:26 AM, ik wrote:
> Doesn't Pascal have something to offer me to deal with it ?
Bitwise operations + inline functions. Covers most of the needs.
thanks,
dmitry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://
That's make this feature very not useful and unneeded.
If I have a C struct that has a non standard bit count, how can I make sure
that I'll have the needed data on the right field, and without any segfult
in the middle ?
Doesn't Pascal have something to offer me to deal with it ?
Ido
http://ik
David Emerson wrote:
I did cast it to boolean! That's why it smells like a bug
var
b : boolean;
begin
b := boolean (6 and 4);
writeln (t_or_f [b]);
A type cast does not changes the value. A typecast merely allows you to
store a value into a field of a different type
same for enu
On Fri 23 Oct 2009, ik wrote:
> The use of 'array[boolean]' does not mean that the array is true or
> false, but rather '0..1'. You indicate a range, not a boolean
> behavior.
Well, pascal is a typed language, so while I do realize that the
information is stored as false=0 and true=1, and that's
On 23/10/2009, Marco van de Voort wrote:
> >
> > You can consider declaring the ID in the header record type as
> > array[1..2] of char.
>
> (starting to use ansichar might not be bad)
Good point. But I preferred to go with array of Byte.
--
Regards,
- Graeme -
_
On 23/10/2009, Vincent Snijders wrote:
>
> You can consider declaring the ID in the header record type as array[1..2]
> of char.
As Marco suggested... Char size might not always be the same. I did
however change my header to array[0..1] of byte instead.
--
Regards,
- Graeme -
___
Do somebody used sphinx2 for speech recognition from Freepascal (or
Delphi) ???
How?
Thanks
Horacio
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Graeme Geldenhuys wrote:
The first item is 31bit and the second item is 1 bit. Does FPC support
a record structure that can define bit level sizes?
I've done this kind of thing quite a bit in the past. Usually, I define
a "raw" version and a "clean" version, and write two routines to conver
Hello all,
I find no instructions howto install fpc on solaris 10 x86. Maybe I'm
googeling wrong...
Yet someone has compiled and some experience?
Any help would be appreciated.
Regards,
Birgit
___
fpc-pascal maillist - fpc-pascal@lists.fre
On 23/10/2009, Jonas Maebe wrote:
>
> The internal format of bitpacked records is opaque, and it is impossible to
> express the alignment requirements of C bitpacked structs or their internal
> fields with them.
So you suggest I continue like I was before? Reading that perticular
piece of data a
Graeme Geldenhuys wrote on Fri, 23 Oct 2009:
uint32_tSearchStart:31;// file offset to full text search table
uint32_tsearchlen:1; // if high bit set, size of
search record size is 16-bit
If not, I guess I can continue with what I already do - read this as
a 32bit u
In our previous episode, Vincent Snijders said:
> > various bits of information, without the need for a hex editor etc...
> > So the solution described earlier will suffice for my needs.
> >
> >
>
> You can consider declaring the ID in the header record type as
> array[1..2] of char.
(starting
ik wrote on Fri, 23 Oct 2009:
You can use bitpacked records:
http://www.google.com/codesearch?hl=en&lr=&q=bitpacked+record+package%3Ahttp%3A%2F%2Fpasxlibbind
\.googlecode\.com&sbtn=Search
Here is an example on how I use it :)
No, you cannot use bitpacked records for C header translations.
Graeme Geldenhuys schreef:
On 23/10/2009, Jürgen Hestermann wrote:
Wouldn't it be more direct to use
Blockwrite(,header.ID,sizeof(header.ID));
I read the complete header structure in one go (155 bytes). I simply
want to output to a text file, a human readable structure of the
complete INF f
On 23/10/2009, Jürgen Hestermann wrote:
>
> Wouldn't it be more direct to use
> Blockwrite(,header.ID,sizeof(header.ID));
I read the complete header structure in one go (155 bytes). I simply
want to output to a text file, a human readable structure of the
complete INF file. The INF file format
You can use bitpacked records:
http://www.google.com/codesearch?hl=en&lr=&q=bitpacked+record+package%3Ahttp%3A%2F%2Fpasxlibbind
\.googlecode\.com&sbtn=Search
Here is an example on how I use it :)
Ido
http://ik.homelinux.org/
On Fri, Oct 23, 2009 at 8:15 PM, Graeme Geldenhuys
wrote:
> Hi,
>
>
Hi,
The first item is 31bit and the second item is 1 bit. Does FPC support
a record structure that can define bit level sizes?
uint32_tSearchStart:31;// file offset to full text search table
uint32_tsearchlen:1; // if high bit set, size of
search record size is 16-bi
I would like my program to output the following:
-
Header Section
header.ID(5348h = "HS")
...
-
Wouldn't it be more direct to use
Blockwrite(,header.ID,sizeof(header.ID));
That would make it robust against changes of ID size and would avoid the
many typ
On 23/10/2009, Jeff Wormsley wrote:
> Oh, I was fairly certain of that. Its just these little routines tend to
> end up in libraries of handy code. I tend to be overly cautious with some
> of these because of that.
Point taken. :-) This code is purposely rewritten and totally
standalone so I
Graeme Geldenhuys wrote:
On 23/10/2009, Jeff Wormsley wrote:
That's dangerous, though, if your magic number's two bytes aren't printable
That should never be a problem for my tool though. The tool I am
writing is specific to the INF help format. The tool dumps the fil
The use of 'array[boolean]' does not mean that the array is true or false,
but rather '0..1'. You indicate a range, not a boolean behavior.
"6 and 4" gives 4, and 4 is above the range of "1" (the highest cell of the
array you declared). If you would have cast it to boolean, or provide a
better usag
On 23/10/2009, Jeff Wormsley wrote:
>
> That's dangerous, though, if your magic number's two bytes aren't printable
That should never be a problem for my tool though. The tool I am
writing is specific to the INF help format. The tool dumps the file
structure to a text file. (I need this for debu
Graeme Geldenhuys wrote:
Hi,
I'm reading in a WORD (2 bytes) from a binary file. I can display the
Hex format of that value without a problem, but I would also like to
display the String value of that WORD variable. It's the first 2 bytes
of a file, which contains the "magic number" of the file
2009/10/23 Aleksa Todorovic :
>
> w: WORD
> ...
> YourString := Chr(Lo(w)) + Chr(Hi(w))
> or
> YourString := Chr(Hi(w)) + Chr(Lo(w))
Ah, thanks. I was close, I used High() and Low() instead. :-( Dope!
--
Regards,
- Graeme -
___
fpGUI - a cross-p
On Fri, Oct 23, 2009 at 14:10, Graeme Geldenhuys
wrote:
> Hi,
>
> I'm reading in a WORD (2 bytes) from a binary file. I can display the
> Hex format of that value without a problem, but I would also like to
> display the String value of that WORD variable. It's the first 2 bytes
> of a file, which
2009/10/23 Graeme Geldenhuys :
> Hi,
>
> I'm reading in a WORD (2 bytes) from a binary file. I can display the
As I pressed the Send button, I thought about trying the following.
And it worked! But is this the best way of doing what I want?
type
TWord = record
b1: Char;
b2: Char;
en
Hi,
I'm reading in a WORD (2 bytes) from a binary file. I can display the
Hex format of that value without a problem, but I would also like to
display the String value of that WORD variable. It's the first 2 bytes
of a file, which contains the "magic number" of the file.
I would like my program t
2009/10/23 JoshyFun :
>
> Since Delphi first streams I had never used pascal "files" anymore,
> they are a lot of restrictive, not thread safe and are very tied to
> which they expect to read/write.
That's kind-of why I wanted to use TFileStream. I use it for reading
binary data, and thought to us
2009/10/23 Aleksa Todorovic :
> constructor Create...;
> procedure WriteStr(const fmt: String; const args: array of const);
> procedure WriteStr(const s: String);
OK, I managed to solve the problem. I have two units that write to the
output text file. The one unit I fixed by using
"AOut.WriteBuff
Zitat von Graeme Geldenhuys :
2009/10/23 Graeme Geldenhuys :
Did you try writing with WriteBuffer(Atext[1], length(AText)?
That works exactly like I intended. Thanks Gerard.
I spoke to soon! :-(
I can view the resulting output.txt file with Midnight Commander
(Linux console file manager)
Hello Frank,
Friday, October 23, 2009, 12:50:22 PM, you wrote:
FP> If you want a text file, why do you not use a variable of type text,
FP> instead of a TFileStream? Text is what writes a text file. I think these
FP> streams are for saving object state, which means they are binary files
TFileStr
On Friday 23 October 2009 11:58:49 Graeme Geldenhuys wrote:
>
> Maybe TFileStream is not suited for plain text output, and I should
> rather use the File type instead?
MSEgui has ttextstream and ttexdatastream, lib/common/kernel/msestream.pas.
http://mseide-msegui.svn.sourceforge.net/viewvc/mseide
On 23/10/2009 11:21, Graeme Geldenhuys wrote:
2009/10/23 Graeme Geldenhuys :
Did you try writing with WriteBuffer(Atext[1], length(AText)?
That works exactly like I intended. Thanks Gerard.
I spoke to soon! :-(
I can view the resulting output.txt file with Midnight Commander
(Linux consol
2009/10/23 Graeme Geldenhuys :
> 2009/10/23 Henry Vermaak :
>>
>> Maybe you need to put the line endings in manually?
>
> What do you mean? I already append LineEnding to AText, and send that
> to WriteAnsiString() call.
That's what I meant (and I just realised you already mentioned it in a
previ
Graeme Geldenhuys schreef:
2009/10/23 Vincent Snijders :
Otherwise you cannot read it back. :-)
But using .WriteAnsiString() doesn't create a plain text file, so the
result is useless.
Is useless for your current use, I admit. Don't use it to create a plain text
file.
But if you want writ
2009/10/23 Henry Vermaak :
>
> Maybe you need to put the line endings in manually?
What do you mean? I already append LineEnding to AText, and send that
to WriteAnsiString() call.
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal G
On Fri, Oct 23, 2009 at 12:25, Graeme Geldenhuys
wrote:
>
> Anyway, so now I'm back to square one - unable to create a plain text
> file with TFileStream. :-(
>
What about:
TFileTextStream = class(TFileStream)
constructor Create...;
procedure WriteStr(const fmt: String; const args: array of cons
Graeme Geldenhuys schreef:
2009/10/23 Vincent Snijders :
Otherwise you cannot read it back. :-)
But using .WriteAnsiString() doesn't create a plain text file, so the
result is useless. And as my last post says, the method Gerard
suggested is also not 100%.
It seems extra hard to create a nor
On Fri, Oct 23, 2009 at 12:21 PM, Graeme Geldenhuys
wrote:
> I can view the resulting output.txt file with Midnight Commander
> (Linux console file manager), but if I try and open that file with
> Gnome gEdit or Lazarus IDE, it says the file does not look like a text
> file and refuses to open it
2009/10/23 Graeme Geldenhuys :
> 2009/10/23 Vincent Snijders :
>>
>> Otherwise you cannot read it back. :-)
>
> But using .WriteAnsiString() doesn't create a plain text file, so the
> result is useless. And as my last post says, the method Gerard
> suggested is also not 100%.
>
>
> It seems extra h
2009/10/23 Vincent Snijders :
>
> Otherwise you cannot read it back. :-)
But using .WriteAnsiString() doesn't create a plain text file, so the
result is useless. And as my last post says, the method Gerard
suggested is also not 100%.
It seems extra hard to create a normal, plain, standard text f
2009/10/23 Graeme Geldenhuys :
>
>> Did you try writing with WriteBuffer(Atext[1], length(AText)?
>
> That works exactly like I intended. Thanks Gerard.
I spoke to soon! :-(
I can view the resulting output.txt file with Midnight Commander
(Linux console file manager), but if I try and open that f
Graeme Geldenhuys schreef:
2009/10/23 Gerard N/A :
Could it be that the length indicator bytes of the string are written
to the stream?
Ah, looking at the .WriteAnsiString() implementation, you seem to be
100% correct.
Procedure TStream.WriteAnsiString (const S : String);
Var L : Longint;
2009/10/23 Marco van de Voort :
>
> if length(atext)>0 then
>>WriteBuffer(Atext[1], length(AText)?
I always add a LineEnding character to AText, so the 'if length()'
check is not strictly needed. Sometimes I would like to write a
"blank" line in my text output. Equivalent of writeln('');
--
R
2009/10/23 Gerard N/A :
>
> Could it be that the length indicator bytes of the string are written
> to the stream?
Ah, looking at the .WriteAnsiString() implementation, you seem to be
100% correct.
Procedure TStream.WriteAnsiString (const S : String);
Var L : Longint;
begin
L:=Length(S)
In our previous episode, Gerard N/A said:
> Could it be that the length indicator bytes of the string are written
> to the stream?
I think his result is a shortstring, and that gets binarily written.
> > Maybe TFileStream is not suited for plain text output, and I should
> > rather use the File t
Hi,
On Fri, Oct 23, 2009 at 11:58 AM, Graeme Geldenhuys
wrote:
> where AOut is the TFileStream. But if I view the output file, it
> "mostly" looks like text. Except that on each line in starts with some
> random 2-3 characters.
>
Could it be that the length indicator bytes of the string are wr
Hi,
How do you create plain text file output with TFileStream? Or is
TFileStream reserved for binary output only?
I'm using TFileStream as follows;
// helper function to simply things
procedure writef(AText: string);
begin
AOut.WriteAnsiString(AText + LineEnding);
end;
where AOut is
50 matches
Mail list logo
