Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Form creation and destroying
« Last post by madref on Today at 12:48:42 am »
I am trying to open an old form I created in my main program.
In the unit where I am opening the form I am using this code:
Code: Pascal  [Select][+][-]
  1.                          fer2019 := TForm_Evaluaties_2019_Referee.Create(Self);
  2.                          fer2019.Evaluatie_ID := Save_ID;
  3.                          fer2019.Wedstrijd_ID := Save_WD;
  4.                          fer2019.Show;
This opens and shows the form.


When I am done with the form I naturally close it with the following code:
Code: Pascal  [Select][+][-]
  1. procedure TForm_Evaluaties_2019_Referee.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  2. begin
  3.   CloseAction := caFree;
  4. end;     // FormClose


My question is: Is the closeaction destroying the form so that the memory it uses is being freed?
2
General / Re: indexind combinations function - math problem
« Last post by dseligo on Today at 12:33:53 am »
TS is talking about combinations (https://en.wikipedia.org/wiki/Combination).

And here is some theory how to solve his problem: https://en.wikipedia.org/wiki/Combinatorial_number_system.
3
General / Re: Which bitness first ?
« Last post by Bart on June 25, 2024, 11:59:24 pm »
On Windows I mainly use 32-bit (because the compiler is natively 32 bit).
I only cross-compile to win64 if I see an advantage (or to check it compiles at all).
I maybe just too lazy to rebuild Lazarus to 64-bit and build all by default to 64-bit.
My hardware surely should not be a  problem.

Bart
4
General / Re: Class and normal (per-instance) fields.
« Last post by MarkMLl on June 25, 2024, 11:22:24 pm »
I see: the duplicated var.

MarkMLl
5
General / Re: Class and normal (per-instance) fields.
« Last post by jamie on June 25, 2024, 10:50:19 pm »
Code: Pascal  [Select][+][-]
  1. TTicket= class
  2. public
  3.  class
  4.    Var
  5.      InfieldDegs: TVertexDegs; (* Used for range calculation           *)
  6.      RadioDegs: TVertexDegs;   (* Used for slant calculation           *)
  7. public
  8. ...
  9.   end;
  10.  

Like that  :D
6
General / Re: Which bitness first ?
« Last post by marcov on June 25, 2024, 10:04:01 pm »
Mainly so that at least someone still checks whether i386-win32 of 3.3.1 is working correctly :P

I build a snapshot several times a week.
7
Other / Re: Can FPC/Lazarus save the World?
« Last post by SymbolicFrank on June 25, 2024, 09:54:36 pm »
The most used languages, JavaScript and C++ have a whole lot of gotchas that make it easy to shoot yourself in your foot. The popular new kid on the block, Go, seems easy at first, the gotchas are there when you want to make it more complex, or multi-platform. And while JavaScript seems ubiquitous, for a serious program Typescript is a must.

JavaScript classes are "meh" and hard to use, Go doesn't have them. And we see that in the programmers: they're streamlined to write very simple code, mostly database lookups that are translated into JSON, or the other way around. Most think classes are scary.

So, simple, dynamic procedural programs are produced. If they grow big and are in JavaScript, you're encouraged to move more of it to node.js on the server. And if you're using Go, you're basically stuck with it, because it's hard to rewrite in another programming environment and Go doesn't talk with other computer languages.

So, it boils down to:
1. Whatever is easiest to start using it (JavaScript)
2. Whatever the Big companies use
3. What we have used for at least the last decade

In contrast, Object Pascal does most things pretty well and bugs and gotchas are actually fixed. It does have some weak points, but nothing as bad as the popular ones. Which do all look like C, so that's to most programmers how a programming language should look like.

And, as said, everything else is marketing.
8
General / Re: Class and normal (per-instance) fields.
« Last post by MarkMLl on June 25, 2024, 09:45:17 pm »
Yes, it's required, because there can be class methods as well not to mention that there can be type and const sections.

Thanks for that, which I think fits in with Jamie's interpretation. It turned out that this form

Code: Pascal  [Select][+][-]
  1. TTicket= class
  2. public class
  3.   var InfieldDegs: TVertexDegs; (* Used for range calculation           *)
  4.   var RadioDegs: TVertexDegs;   (* Used for slant calculation           *)
  5. public
  6. ...
  7.   end;
  8.  

was problematic, and in the end I've written it as

Code: Pascal  [Select][+][-]
  1.   TTicket= class
  2.     class var InfieldDegs: TVertexDegs; (* Used for range calculation           *)
  3.     class var RadioDegs: TVertexDegs;   (* Used for slant calculation           *)
  4.   public                                (* This is needed to close var section  *)
  5.     Timestamp: TDateTime;
  6. ...
  7.  

and to Hell with the verbosity :-)

MarkMLl
9
General / Re: Class and normal (per-instance) fields.
« Last post by PascalDragon on June 25, 2024, 09:19:46 pm »
It seems the compiler is ok, it's just that VAR being presented in a block is the same as it would be in a start of a block statement.

That's a good point. Is it actually needed, or would simply making it look like an ordinary field work?

Yes, it's required, because there can be class methods as well not to mention that there can be type and const sections.
10
General / Re: indexind pointer
« Last post by TRon on June 25, 2024, 09:16:06 pm »
Code: Pascal  [Select][+][-]
  1. p := GetMem(sizeof(Double)*n);
  2.  
  3. for i :=  0 to N-1 do
  4.  p[i] := sin(i*pi/N);
  5.  


this is safe, and natural;

If you truly have the believe that the code as posted represents safe programming then I'm sorry to remark (e.g. not meant to offend) , that there is something seriously wrong with either the concept of safe programing or your interpretation of that concept (My bet would be on the latter  :) ).

It is lacking some serious defensive programming and is a good example of why it doesn't matter how much safety is present in the language/compiler itself that bad code will still be bad code no matter what.

That doesn't take away the fact that if you wish to do exactly that, that you can do exactly that what you can do in c you can do in Pascal as well.
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018