On 6/24/2011 4:52 PM, Krzysztof wrote:
I had similar problem, I think that this is because consts are "filled"
when compiling and there is no way to change them at runtime. Try this
trick with pointers:
Thanks Krzysztof. That looks like the least invasive approach, so if I
can't get them work
On 6/24/2011 4:14 PM, Marco van de Voort wrote:
No, this is a problem of gettext.
It's a problem with FPC's resourcestring implementation, rather than
something specific to gettext. I could use SetResourceStrings directly
(objpas.pp) and it will have the same issue.
For this to work you real
Hi,
I had similar problem, I think that this is because consts are "filled" when
compiling and there is no way to change them at runtime. Try this trick with
pointers:
resourcestring
SSunday = "Sunday";
const
SWeek: array[0..0] of PString = (@SSunday);
begin
WriteLn(SWeek[0]^);
end;
Regards
In our previous episode, Craig Peterson said:
> In Delphi I can use resource strings with const arrays and everything
> works correctly. For example, if I have a resource DLL with translated
> strings and this will work:
>
> resourcestring
>SSunday = "Sunday";
>
> const
>SWeek: array[0
In Delphi I can use resource strings with const arrays and everything
works correctly. For example, if I have a resource DLL with translated
strings and this will work:
resourcestring
SSunday = "Sunday";
const
SWeek: array[0..0] of string = (SSunday);
begin
WriteLn(SWeek[0]);
end;
I'v
Am Freitag, 24. Juni 2011 19:55 schrieb fluisgira...@gmail.com:
> Some years ago, I started the port of my project (PascalSCADA) from
> Windows to others platforms. I found some issues doing this. I used
> all resources that the FPC RTL can offer.
>
> To thread, I used TThread class. The issues tha
Some years ago, I started the port of my project (PascalSCADA) from
Windows to others platforms. I found some issues doing this. I used
all resources that the FPC RTL can offer.
To thread, I used TThread class. The issues that I found porting this,
is that Suspend/Resume don't works on others plat
Hi,
I'm puzzled by some of the code generated for x64. Came across this
earlier post;
http://www.hu.freepascal.org/lists/fpc-pascal/2005-March/008175.html
Compiling the simple example with the loop in a function I get much
leaner & meaner than the [i386] assembler in the original post, but I
Rewrite the threading code with FPC one (i.e. BeginThread - EndThread, or the
more beautiful TThread). WaitForSingleObject... I've never used this,
perhaps SyncObjs and its critical section handler? CloseHandle: depending on
how you open it, close with its correct pair.
--
View this message in con
> If that the reason you like FPC, then something is wrong :P
Having a FAST compile time is one of the reason I like FPC (or any Pascal
compiler in general, most of them also compiles fast).
> Try to compile any C++ program using g++, and you'll figure it out
> yourself.
Yup, 40 minutes bootstra
On Fri, 24 Jun 2011 16:56:09 +0200
fred f wrote:
> Hi,
>
> What's wrong on this condition to get the code running on 32 and 64bit:
>
> // Get pointer to varlength data.
> function GetVarLengthData(AVarLength:PAnsiChar):PAnsiChar;
> begin
> Result:=PAnsiChar(AVarLength){$IFDEF
> FPC}+SizeO
Hi,
What's wrong on this condition to get the code running on 32 and 64bit:
// Get pointer to varlength data.
function GetVarLengthData(AVarLength:PAnsiChar):PAnsiChar;
begin
Result:=PAnsiChar(AVarLength){$IFDEF FPC}+SizeOf(PtrInt){$ELSE}+4{$ENDIF};
end;
Thanks in advance.
F.
_
On Fri, Jun 24, 2011 at 2:42 PM, ik wrote:
> If that the reason you like FPC, then something is wrong :P
Clearly you didn't pay enough attention while reading his post and
missinterpreted it.
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist -
On Thu, Jun 23, 2011 at 10:09, Graeme Geldenhuys wrote:
> Hi,
>
> I know I'm sometimes hard on some developers. I guess sometimes one has
> to sit back and see the big picture too. While reading the following
> text from the OpenWatcom newsgroups, it made me realize what a great
> compiler and pro
On 24 Jun 2011, at 13:08, Alain Van Muylem wrote:
I discovered Free Pascal yesterday and I am working at recompilying
my old Turbo Pascal (5.0) files. The first problem (but probably not
the last) I encountered is the reading of my old data files (files
of record of real) because of the 6
Dear all,
I discovered Free Pascal yesterday and I am working at recompilying my old
Turbo Pascal (5.0) files. The first problem (but probably not the last) I
encountered is the reading of my old data files (files of record of real)
because of the 6 byte coding for real type in Turbo Pascal ver
That did the trick.
Carsten
> MSDN states that the first ShowWindow is ignored if a STARTUPINFO is
> provided.
>
> winhello.pp has
> ShowWindow(hWindow, CmdShow);
> ShowWindow(hWindow, SW_SHOW);
> This is the difference with your test program.
>
> Ludo
>
> > -Message d'origine-
> >
Hi,
I know I'm sometimes hard on some developers. I guess sometimes one has
to sit back and see the big picture too. While reading the following
text from the OpenWatcom newsgroups, it made me realize what a great
compiler and programming language we are using.
A big thanks to the FPC team for ma
On 24 Jun 2011, at 00:06, Darius Blaszyk wrote:
I'm porting an app from delphi to lazarus and now I reached a
problem when trying to link to the library. The library comes with
the .dynlib .a and all header files. I placed them somewhere under
my homedir and added the following to my code:
MSDN states that the first ShowWindow is ignored if a STARTUPINFO is
provided.
winhello.pp has
ShowWindow(hWindow, CmdShow);
ShowWindow(hWindow, SW_SHOW);
This is the difference with your test program.
Ludo
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org
>
20 matches
Mail list logo
