On 20/05/2019 11:01 pm, Giuliano Colla wrote:
> In some rare case when dealing with complex objects you might need
> FreeThenNil() in place of FreeAndNil().
As far as I'm concerned, that is such a broken concept! The developer
already has the burden to free any memory that he/she allocates. With
I have this program that is confounding me.It obtains a file name with
GetOpenFileNameA then it processes the file and draws stuff on the screen, then
loops back and gets another file name until GetOpenFileNameA returns a false…
so as long as I keep giving it files it keeps running and if I
This is my function that seems to cause this more than anything else… it’s
ridiculously simple…
Function ExtractFilePathAndNameWithoutExt(Filenametouse:String):String;
Begin
ExtractFilePathAndNameWithoutExt :=
copy(Filenametouse,1,rpos(ExtractFileExt(Filenametouse),Filenametouse)-1);
E
On Tue, 21 May 2019, Graeme Geldenhuys wrote:
On 20/05/2019 11:01 pm, Giuliano Colla wrote:
In some rare case when dealing with complex objects you might need
FreeThenNil() in place of FreeAndNil().
As far as I'm concerned, that is such a broken concept! The developer
already has the burden
I don’t seem to have FreeThenNil I’m using FPC 3.0.4RC1 I don’t use Lazarus..
maybe it’s a Lazarus thing… or maybe it’s in a different unit
plotdraw.pax.pas(20,7) Error: Identifier not found "FreeThenNil"
James
From: fpc-pascal On Behalf Of
Giuliano Colla
Sent: Monday
Op 2019-05-21 om 14:18 schreef James Richters:
Does anyone have any idea at all why RPOS could not determine that the
position of .dpax in M:\elipse_1.dpax was 12 like every other time I
ran this
I ran this while looking at task manager and it starts up with 9.2MB
of memory and
I'll try your ideas on how to track this down.
I wonder if I am really having some kind of other issue... maybe RPOS is using
the stack and I'm running out of space or some other kind of memory issue.
It seems odd that I can run this routine dozens of times successfully and then
I get this acce
I'm not sure your familiarity with debuggers but you would set a breakpoint inside your code and step through until it crashes, perhaps watching a few variables to ensure their contents are correct.Since it would work similar to turbo pascal and by extension, more modern "clone"/work-alikes, the vi
James Richters schrieb am Di., 21. Mai
2019, 15:48:
> I don’t seem to have FreeThenNil I’m using FPC 3.0.4RC1 I don’t use
> Lazarus.. maybe it’s a Lazarus thing… or maybe it’s in a different unit
>
Correct, it's part of Lazarus.
Regards,
Sven
>
___
Il 21/05/2019 14:40, Michael Van Canneyt ha scritto:
FreeThenNil should never be necessary. FreeAndNil() should be enough
for all circumstances.
In a perfect world maybe you're right. But if you're dealing with LCL,
you'll find it sometimes necessary, less your program segfaults, because
th
On Tue, 21 May 2019, Giuliano Colla wrote:
Il 21/05/2019 14:40, Michael Van Canneyt ha scritto:
FreeThenNil should never be necessary. FreeAndNil() should be enough
for all circumstances.
In a perfect world maybe you're right. But if you're dealing with LCL,
you'll find it sometimes nece
Hi,
On 21/05/2019 4:36 pm, Michael Van Canneyt wrote:
> In that case the lazarus devels should fix whatever causes this.
>
> Delphi does not have this after all, so it is possible to create a set of
> GUI components that does not need it. It may not be easy, but you cannot
> expect a user to find
On Tue, 21 May 2019 16:47:28 +0100
Graeme Geldenhuys wrote:
>[...]
> I fully agree with what Michael said. You can't truly expect
> applications developer to trail and error what needs to be done. It's
> an LCL issue that the Lazarus project needs to fix. Delphi's VCL,
> fpGUI Toolkit and MSEide+
On Tue, 21 May 2019, Mattias Gaertner via fpc-pascal wrote:
On Tue, 21 May 2019 16:47:28 +0100
Graeme Geldenhuys wrote:
[...]
I fully agree with what Michael said. You can't truly expect
applications developer to trail and error what needs to be done. It's
an LCL issue that the Lazarus proj
On Tue, May 21, 2019 at 2:18 PM James Richters
wrote:
> Function ExtractFilePathAndNameWithoutExt(Filenametouse:String):String;
>
> Begin
>
>ExtractFilePathAndNameWithoutExt :=
> copy(Filenametouse,1,rpos(ExtractFileExt(Filenametouse),Filenametouse)-1);
>
> End;
From LazFileUtils unit:
fu
Thanks for the function. I don't think that my function is the problem at
all.. I've just completed a test where I bypassed my file list and ran it
several hundred times and my function never caused any problems I think I
have a fundamental problem with the function I disabled to get it to
This is the function I came up with to use GetOpenFileNameA() to get multiple
files, and put the file names all into a StringList.
I think I am doing something fundamentally wrong here because I can run this in
a loop sometimes 2 or 4 times, or sometimes 30 times, and it seems to work but
event
On 21.5.2019 22.12, James Richters wrote:
This is the function I came up with to use GetOpenFileNameA() to get multiple
files, and put the file names all into a StringList.
I think I am doing something fundamentally wrong here because I can run this in
a loop sometimes 2 or 4 times, or sometim
I have it defined with the program variables:
Here are all my Uses and Vars:
Uses
ptcgraph,sysutils,Windows,Commdlg,Classes,CRT;
Var
TFilename : TOpenFileNameA;
ret: array[0..100] of char;
OpenFileResult : Boolean;
LoopX,filenum : Longint;
file
19 matches
Mail list logo
