Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
LCL / Re: Screen.Monitors[x] Returns incorrect Left properties
« Last post by Tony Stone on Today at 02:53:28 am »
I don't have a setup near me with multiple monitors so it's hard for me to decide however, I am sure you are not on windows and this leads me to believe that maybe there is a widget issue that could be reporting bad info.

  Have you determined if the returned info is correct from the monitor's array ?

  Also, if that is correct then maybe it could be a form issue but that could still be a widget issue, too.

Well... I am still slowly working things out.  I found that rebooting my computer I am not getting proper info back from the array of monitors.  It may have been due to changing monitor settings through the Linux Mint Display Manager.  So to that end, no I am not on windows.

So what I am struggling with now is  getting my displays(tpanels are used to represent a display) to scale down and fit in the main panel...  like my screen shots show.  Mathematically I know how to scale it down but I am running into issues with division.  I am close to working it out though.  Will report back soon.
 :-[
2
LCL / Re: Screen.Monitors[x] Returns incorrect Left properties
« Last post by jamie on Today at 02:49:05 am »
I don't have a setup near me with multiple monitors so it's hard for me to decide however, I am sure you are not on windows and this leads me to believe that maybe there is a widget issue that could be reporting bad info.

  Have you determined if the returned info is correct from the monitor's array ?

  Also, if that is correct then maybe it could be a form issue but that could still be a widget issue, too.
3
LCL / Re: Screen.Monitors[x] Returns incorrect Left properties
« Last post by Tony Stone on Today at 02:30:25 am »
So part of my code was completely wrong.  So the demo project is probably useless.... however.... i still l cannot seem to get the proper Left value for the upper monitors.
4
I'll provide an example as soon as get a chance.
5
LCL / Screen.Monitors[x] Returns incorrect Left properties
« Last post by Tony Stone on Today at 01:14:30 am »
It is hard for me to explain so i created a couple screen shots and a demo project.  But I need to basically draw my multi monitor display on a form.  The problem is some of the monitors are returning the wrong left values.  I am showing my real monitor layout and what my program is calculating.


It seems to only return improper left values for the top row of monitors.

I am trying to write an application to help setup xrandr so I can ultimately use this to call commands to xrandr
6
Lazarus / Re: Lazarus Release Candidate 2 of 2.2.0
« Last post by Martin_fr on Today at 12:53:54 am »
I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Setting "debug info" to none, does not mean to not have a debugger. (Though admittedly, it leaves the debugger *almost* useless).

With the "debug info" = none, I can
- compile
- run without debugger (from the menu)

Only when I do F9 (or normal "run"), which means run in the debugger, then the dialog comes.

Indeed, the old IDE did not care (and IIRC, if you switch the new IDE to use gdb, then it wont care either).
The old IDE did happily let you run your app in the debugger, without debug info present. That means all the debugger could do, is give you assembler, if you paused the app.

Assign a key to "run without debugger" and use that instead. Since you do not want to debug anyway.


Both behaviours have there pro and con.
- the old: if you really did just want to "run without debugger", you could ignore that there was a debugger present. In *most* cases it was unnoticeable.
- the new: if you do want to debug, its nice to know that you need to fix the settings.

7
Lazarus / Re: Lazarus Release Candidate 2 of 2.2.0
« Last post by Martin_fr on Today at 12:35:17 am »
I encounter a nasty regression:

- I compile projects last time compiled using 2.2.0 RC1 with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

As result I get not tons of these changes to the .lfm file which are obviously wrong, see the attached screenshot.

Update your Fpc 3.2.3

The snapshot you have as a bug, and that leads to plenty of integer values being replaced with color names.


Be aware, that most likely once an lfm has been "corrupted" it can only be read with the faulty version that wrote it. So check, if you have backups.
8
Beginners / Re: Generic methods, fpc 3.2.2
« Last post by jamie on Today at 12:14:44 am »
Here's my take on it...

As simple as I can make it...

Please read the comments I placed in code here, there is no need to test compile this of course.

Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
  9.  
  10. type
  11.   //Following is a blue print to be used later to create an actual type.
  12.   generic test<T>=Class  //create a base template for the compiler to read when needed.
  13.     aField:T;
  14.   End;
  15. // Following are actual types being created using the Generic Template as the reference.
  16. // Specifying a <TYPE> now makes a complete type define using the BASE to start with;
  17.   TNewTypeInt = specialize Test<Integer>; //Now actually Create the type with Integers;
  18.   TNewTypeFloat = specialize Test<Double>;//Now actually create the type with floats;
  19.   //After this the compiler now has two types as if you were to type them out manually yourself.
  20.   //Note: you can only instruct FPC to Specialze once per type, otherwise it's a dup of course.
  21.   //  you would think only a hint of location where it was specilized aready would be enough?
  22.   { TForm1 }
  23.  
  24.   TForm1 = class(TForm)
  25.     Button1: TButton;
  26.     procedure Button1Click(Sender: TObject);
  27.   private
  28.  
  29.   public
  30.  
  31.   end;
  32.  
  33. var
  34.   Form1: TForm1;
  35.   aNewTypeInt :TNewTypeInt; //declare an instance body pointer;
  36.   aNewTypefloat:TNewTypeFloat;//Declare an instance body pointer;
  37.  
  38. implementation
  39.  
  40. {$R *.lfm}
  41.  
  42. { TForm1 }
  43.  
  44. procedure TForm1.Button1Click(Sender: TObject);
  45. begin
  46.    aNewTypeInt := TNewTypeInt.Create; //Create the instance so the the "aField" member has memory.
  47.    aNewTypeFloat:= TNewTypeFloat.Create;// "" "" ect.
  48.    AnewTypeInt.AField := 1;
  49.    AnewtypeFloat.aField := 1.56;
  50.    aNewTypeInt.Free;
  51.    aNewTypeFloat.free;
  52. end;
  53.  
  54. end.
  55.  
  56.  
9
Lazarus / Re: Lazarus Release Candidate 2 of 2.2.0
« Last post by Muso on November 26, 2021, 11:42:33 pm »
there is: I change with a text editor
- LCLVersion = '2.2.0.2'
+ LCLVersion = '2.2.0.3'

This does not work. I now get also the attached. So the bug is not in the LFM file conversion.
10
Lazarus / Re: Lazarus Release Candidate 2 of 2.2.0
« Last post by Muso on November 26, 2021, 11:37:48 pm »
There is an other regression to RC1:

I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018