Recent Posts

Pages: 1 2 [3] 4 5 ... 10
General / Re: Question ?!!!!
« Last post by 440bx on Today at 12:21:51 pm »
in my oppinion it brings too much overload to the language syntax.
On the contrary, unlike inline variables it does not overload the "begin" and "end" keywords as block delimiters.

I think a feature like this is justified only if it brings considerable gains in performance.
That feature has nothing to do with performance.  It wouldn't affect performance one way or the other.  What that feature is about is localizing constant, type and variable definitions within a function/procedure.  That means, instead of potentially having a significant number of locals, which turn out to be globals within the function/procedure/method, it would allow a much smaller number of locals because "throw away temporary variables" would be confined to the scope.  That would make the code easier to understand and maintain.

By the way, would not this syntax cause some confusion with a possible future implementation of anonymous methods?
It shouldn't.  Inline scopes should always be identified by a keyword to indicate their presence.

Delphi actually allows scoping inline variables if you put then INSIDE a nested begin..end block.
THAT is syntax overloading.  "begin"/"end" are very poor block delimiters.  The reason is, in a Pascal block, the programmer is supposed to be able to declare constants and types but, apparently these block features would not be available by overloading "begin"/"end".  Overloading "begin"/"end" as block delimiters is just a hack.  Another "writable constants" bright idea.

Type inference makes some assignments a little less redundant to write and adds simplicity to the code. The only negative point I see is the syntax that not follows the original Pascal concepts of declaring everything BEFORE the begin..end;
That's not the only potential problem with type inference.  Pascal's strong type checking depends on explicit type declarations, type inference has the potential to create situations where the compiler would infer a type that is not the one the programmer had in mind.

However, I wish I could declare a variable in a loop like this in FPC:
Code: Pascal  [Select][+][-]
  1. for var i := 1 to 5 do
With inline scopes you can do that and then some, all without altering the way variables are declared.

but I understand that if it costs turning the language into a Frankenstein, with various pieces without consistency, I prefer FPC stays the way it is.
Too late for that.  If memory serves, writable constants were the first "Frankengimmick" that Borland put into Pascal and, unfortunately, far from the last one.

Fortunately, or maybe unfortunately, it's quite likely that the probability of seeing the Pope named the sexiest male on earth is likely greater than seeing inline scopes implemented in FPC.

hence I suggested for the latter example to create index as a keyword. The compiler can know that an index variable is required, even nested, and the ugly var is gone.
Code: Pascal  [Select][+][-]
  1. // in this case suppose index is a keyword, requesting the compiler to create it
  2. for index := 0 to 4 do
  3.   for index := 3 to 7 do;
Effect is the same, but I believe the syntax is a lot cleaner..
And how would a two dimensional array "A" element be addressed ?... A[index, index] ? being able to address only the elements on the diagonals of square arrays doesn't seem to be a very useful "feature".

As far as controlling repetitions, that nested loop is basically a convoluted way of writing "for i := 1 to 25 do ;"  The other examples you showed have the same problems.

Beginners / Re: TImage behavior
« Last post by Birger52 on Today at 12:19:25 pm »
Description of the AutoSize property:
"Allows to automatically adjust the size of the control, according to its content."
This should IMHO mean, that a TImage assumes the size of the image drawn on screen.
What it actually does, seems to be a mix - the height is set according to constraints, image scaled to fit, and width is set to the original, and not the scaled image.
Constraints: "The minimal and maximal Width and Height of this control."

Not setting AutoSize to true, makes the width of the TImage a default size - the size a TImage gets, if it is just dropped at designtime, if it is not limited by the constraint width.
I tried setting a smaller width - but that apparently overwrites Constraints!

Changed programming, so scaling is done manually.
Image created like this:
Code: Pascal  [Select][+][-]
  1. constructor TPlayImage.Create(aInfo:TPlayInfo; aHeight:integer);
  2. begin
  3.   inherited Create(aInfo);
  4.   Parent := aInfo;
  5.   FCont := AInfo.FCont;
  6.   Color := clNone;
  7.   Width := aHeight;
  8.   Height := aHeight;
  9.   Name := 'Image_'+IntToStr(aInfo.FIndex);
  10.   StretchInEnabled := true;
  11.   Proportional := true;
  12.   AnchorSide[akLeft].Side := asrLeft;
  13.   AnchorSide[akLeft].Control := aInfo;
  14.   AnchorSide[akTop].Side := asrCenter;
  15.   AnchorSide[akTop].Control := aInfo;
  16.   BorderSpacing.Left := 4;
  17.   BorderSpacing.Around := 1;
  18.   Anchors := [akLeft, akTop];
  19.   DragMode := dmManual;
  20.   DragKind := dkDrag;
  21. end;
Then loading and scaling the image like this
Code: Pascal  [Select][+][-]
  1. procedure TPlayInfo.SetInfo(aImg, aTxt:string);
  2. var
  3.   fWidth, fHeight : integer;
  4.   psc, hsc : real;
  5. begin
  6.   FImage.Picture.LoadFromFile(aImg);
  7.   fWidth := FImage.Picture.Bitmap.Width;
  8.   fHeight := FImage.Picture.Bitmap.Height;
  9.   psc := FMaxImgSize/fWidth;
  10.   hsc := FMaxImgSize/fHeight;
  11.   if (psc > hsc) then psc := hsc;
  12.   if psc > 1 then psc := 1;
  13.   fWidth := round(fWidth*psc);  // Billeddimension i pixels
  14.   fHeight := round(fHeight*psc);
  15.   FImage.Width := fWidth;  // Billeddimension i pixels
  16.   FImage.Height := fHeight;
  17.   FInfoLabel.Caption := aTxt;
  18.   Refresh;
  19. end;
It may not be optimal - but in contrast to what would be logical (from documentation) this has the advantage, of actually producing the desired results.
General / Re: event deactivate component
« Last post by jamie on Today at 12:09:00 pm »
Hmm, does Linux widgets support the non client mouse click messages ?

LM_NCLBUTTONUP for example in the message loop ?

 If so you can simply hook the message loop and decide what to do with it there.
General / Re: Vector Drawing - where to start?
« Last post by wp on Today at 12:01:47 pm »
The problem I had was understanding why it had to be so complex.
Complex? Maybe because I'd had never heard of this kind of polygons and did it in the first way that came to my mind. Feel free to improve it.

I chose an OOP solution because I intended to separate polygon generation (Define) and drawing processes (Draw). I did not utilize this in the demo where they all happen in the same OnPaint event handler of the drawing object, but this is not optimal. It would be better to create the TReubeauxPolygon only when the parameters (radius, vertex count, diameter) change and in the OnPaint to only call Draw. Of course the same effect can be achieved by procedural programming, but I think this is a nice example for OOP.

   The basic tenet of my project started out as how to calculate the area of a Reuleaux Polygon given only the Constant Diameter [D] and the Number of Sides [N]. That meant that I had to find what you term 'CircleRadius' from those and it is as simple as   2/D/cos(pi/(2N))  and by the time you need to call that function you have  - FDiameter and FNumPoints  so you don't need Phi, P1, P2 or Dia  since
result := FDiameter / 2 / Cos(pi / (2*FNumPoints));
Again, when you know a better solution use it, I did not claim my calculation to be optimized.

Your 'float' variable declarations are all 'Double', but these will never be greater than 1000 - probably < 600 - so I can't see why they need to be anything more than 'Single'. I did try to change a number of them but got compiler errors, most likely because I didn't change every instance !!   Is there any reason that they should be 'Double'?
Even FNumPoints - which will never be more than 13   -   OK I see you did set a limit of 101 but beyond 19  the image is indistinguishable from a circle  -  so why not 'Byte'?     Am I just old school still stuck with thinking I have limited memory?   :D
I just gave up such kind of micro-optimizations for "normal" programms and use double for floating point numbers and integer for integer numbers. It's wasted time hunting for bugs because I forgot that a variable is declared as byte but I assigned a value of -1 to it to indicated that its value has not yet been set by the user.

In TReuleauxPolygon.Define you assign all the passed variables  - prefixed 'A', to new variables prefixed 'F'  --  I see that they are declared in the TReuleauxPolygon 'Class'  --  is this just a byproduct of OOP design ?    As you can probably tell, I'm not into OOP !  :o    this project is the first time I've used a 'Class'  -  and that is only down to your declaration.
This a consequence of the fact that the class TReubeauxPolygon does primarily two tasks: prepare the vertices of the polygon (Define) and draw the ReubeauxPolygon (Draw). Both methods need access to the parameters which must be stored therefore.

As for the 'A' and 'F': it is common practice to prefix variables passed as arguments to a procedure by 'A', and to prefix object field variables by 'F'. Additionally I follow the convention to write constants in upper case and local variables in lowercase/CamelCase. Already in a small program, there are so many identifiers that it is hard to tell what they are. And such conventions are a great help.
Russian / Re: Лазарус на MacOS
« Last post by mig-31 on Today at 10:37:21 am »

Of course your way is also proper, by the official documentation

This means even on Unix, paramstr(0) returns the full path to the program executable
General / Re: Question ?!!!!
« Last post by Thaddy on Today at 10:32:53 am »
hence I suggested for the latter example to create index as a keyword. The compiler can know that an index variable is required, even nested, and the ugly var is gone.
Code: Pascal  [Select][+][-]
  1. // in this case suppose index is a keyword, requesting the compiler to create it
  2. for index := 0 to 4 do
  3.   for index := 3 to 7 do;
Effect is the same, but I believe the syntax is a lot cleaner..
Other example I thought of is to extend for to forindex, like:
Code: Pascal  [Select][+][-]
  2. // this assumes forindex is a new keyword in the for family
  3. forindex :=0 to 4 do
  4.   forindex := 3 to 7 do;

And I also thought of simply:
Code: Pascal  [Select][+][-]
  1. for 0 to 4 do
  2.   for 3 to 7 do;
All are to simplify for loop syntax. All are possible. All are things that are not necessary, but at least they are more natural.
LCL / Re: Very serious flicker when StringGrids on PageControl
« Last post by GetMem on Today at 09:39:17 am »
The flicker is clearly visible on slower machines. @Martin_fr explained what causes the issue. I attach a windows only, pseudo solution, which will work, but the flickering should be fixed in LCL.
LCL / Re: Very serious flicker when StringGrids on PageControl
« Last post by trev on Today at 09:29:48 am »
Video drivers?
General / Re: TicTacToe_game (3*3) with AI
« Last post by Mr.Madguy on Today at 09:25:21 am »
3x3 is so easy, that you can actually take all variants into account, i.e. build complete game tree.

Try this heuristic. I haven't tested it, but it should work. Check every cell and calculate weight as follows.
Weight[X] = number of lines, that cross this cell, that:
[1] Have 2 our X or O
[2] Have 2 enemy X or O
[3] Have 1 our X or O
[4] Aren't blocked by enemy X or O

Then Weight = Weight[1] * 1000 + Weight[2] * 100 + Weight[3] * 10 + Weight[4]

Then pick one with highest Weight.

P.S. This AI seems to be working. Only problem - it uses first available "best" move, not random one from list of equal ones.
Not only on Win10: it also flickers on Win7/64!
Pages: 1 2 [3] 4 5 ... 10

TinyPortal © 2005-2018