Re: [Lazarus] tsqlquery to excel

2024-09-11 Thread Ondrej Pokorny via lazarus

On 05.09.2024 22:23, Larry Dalton via lazarus wrote:

That’s what I thought. Any Excel experts out there who use Lazarus?


Check https://wiki.lazarus.freepascal.org/FPSpreadsheet

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Getting notified when active editor changes

2024-08-03 Thread Ondrej Pokorny via lazarus

On 03.08.2024 15:11, Michael Van Canneyt via lazarus wrote:
I implemented an initial version of this new feature, I pushed it to 
the git repo.


I always wanted to do this for the project inspector. So I used your 
approach as an inspiration :)


I also found out that LazarusIDE.RemoveAllHandlersOfObject doesn't 
remove the SourceEditorManagerIntf events. I fixed that in your code.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] MJPEG streamer

2023-07-28 Thread Ondrej Pokorny via lazarus
Just to make sure: do you show a real-time video stream in TImage or do 
you just extract a single frame from the camera one by one?


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] MJPEG streamer

2023-07-28 Thread Ondrej Pokorny via lazarus

On 28.07.2023 03:40, Steve Gatenby via lazarus wrote:


On 24/7/23 09:35, Steve Gatenby via lazarus wrote:


On 23/7/23 18:35, Steve Gatenby via lazarus wrote:
Would anybody know if there is a component / code to enable reading 
an mjpeg stream from a http camera to a Lazarus form/panel (or 
anything really)


Dont mind installing libraries etc -

Looking to suit Linux specifically though

Thanks - SteveG



Thank you all -

exactly what I was hoping for - possibilities to follow :)

I will post if / once I get it figured as may be useful to others


I have written a (very) small unit to capture stream from esp32-cam 
(currently) and display in standard Lazarus TImage. First draft allows 
multiple cams / images.


What is the accepted way of supplying for use by others ? - do we have 
a central place for snippets / units for Pascal / Lazarus.


I know about CCR etc, but this is a bit small for that :) - so not 
sure what to do with it.


Have considered github, but seems overkill for such a small offering 
(and no guarantees it would always exist)


I am interested in your solution.

If the unit uses the Lazarus-included lazvlc.lpk (or any other solution 
included in FPC/Lazarus), I would store it in the examples folder within 
Lazarus main: 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/examples


Please either create an issue in Lazarus gitlab and send the code there 
or send me the example as zipped file and I will upload it to examples.


Thanks,
Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] MJPEG streamer

2023-07-23 Thread Ondrej Pokorny via lazarus

On 23.07.2023 10:35, Steve Gatenby via lazarus wrote:
Would anybody know if there is a component / code to enable reading an 
mjpeg stream from a http camera to a Lazarus form/panel (or anything 
really)


Dont mind installing libraries etc -

Looking to suit Linux specifically though


I would try the VLC player component:
https://wiki.freepascal.org/Video_Playback_Libraries
http://lazplanet.blogspot.com/2018/01/how-to-make-simple-video-player-in.html

VLC can open a video stream from a RTSP camera.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-14 Thread Ondrej Pokorny via lazarus

On 14.06.2023 21:52, Vojtěch Čihák via lazarus wrote:


Hi,


I have one more question to DoAutoAdjustLayout();.

I use TECSpinBtns (TGraphicControl) in two variants:

The first as a stand-alone component and the second as a part of 
TECSpinEdit (where TEdit is Owner and TECSpinBtns is subcomponent 
anchored to it).


When I put them on the form, DoAutoAdjustLayout() is triggered only in 
the first case.


Is it that Owner is responsible to call DoAutoAdjustLayout() of owned 
controls?


This is strange. All controls should be adjusted regardless of the 
Owner. TLabeledEdit works fine (edit that has an attached label).


Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus

On 08.06.2023 19:30, Giuliano Colla wrote:

Il 08/06/23 18:40, Ondrej Pokorny via lazarus ha scritto:

And because it is so much fun, I wrote a completely general program 
to test it.


Well you've shown that it isn't so bad. But there's another detail to 
consider, when resizing: font size. Font size can (and should be) 
specified in typographic points, in order to ensure that text is both 
readable and not too large. i.e. in units which are 1/72". Resizing 
when text size is specified in inches, i.e. in its actual, system 
independent, size, while width and height are specified in pixels i.e. 
in system dependent units is the best way to create the mess which is 
there since the early times of Delphi.


Font size/height are not scaled. The TFont.PixelsPerInch property is 
directly assigned to the target value, so there cannot be a scaling 
problem there.


See TControl.ScaleFontsPPI and TControl.DoScaleFontPPI.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus
And because it is so much fun, I wrote a completely general program to 
test it.


You can define how many resolution combinations you want to go through 
and what maximum value you want to start with and it goes through all 
possible combinations and gives you results after how many cycles a 
start-end pair has settled down and what was the maximum difference.


E.g. for the most typical use-case of 2 different resolutions and max 
scaling of 200% and max starting value of 2000, the results are:


-- Input --
Possible resolutions: 100%, 125%, 150%, 175%, 200%
UniqueCombinations: True
ResolutionSteps: 2
MaxValue: 2000
-- Results --
Count: 40020
Error count after the cycle #1: 5615 (14,03%)
No errors after cycle #2
Maximal error value (difference between start and end value): 1 (5,88% 
from value 17 to 18 for combination 10)


So not really bad, after the 1st cycle the value always settles down and 
the maximal error is 1px, which is ~6% of the start value.


-

For 3 different resolutions (100%, 125%, 200%), the maximum error value 
is 2px after max 10 resolution changes:


-- Input --
Possible resolutions: 100%, 125%, 200%
UniqueCombinations: False
ResolutionSteps: 10
MaxValue: 500
-- Results --
Count: 29583048
Error count after the cycle #1: 6805918 (23,01%)
No errors after cycle #2
Maximal error value (difference between start and end value): 2 (9,52% 
from value 21 to 19 for combination 21)


--

But even after 8 resolution steps (using 5 different resolutions), the 
error is not that bad:


-- Input --
Possible resolutions: 100%, 125%, 150%, 175%, 200%
UniqueCombinations: False
ResolutionSteps: 8
MaxValue: 500
-- Results --
Count: 195702624
Error count after the cycle #1: 82854224 (42,34%)
Error count after the cycle #2: 9545914 (4,88%)
Error count after the cycle #3: 184165 (0,09%)
No errors after cycle #4
Maximal error value (difference between start and end value): 5 (26,32% 
from value 19 to 14 for combination 32401201)


-

To sum it up, for 3 and less monitor DPI resolutions, the maximum error 
is 2px, which is marginal and it is there only for the very small value 
of 19px.


When the number of different resolutions increases (in the above example 
5 different resolutions), the error gets higher, but still is acceptable 
and the higher the starting value, the lower the rounding error. And 
honestly, who has 5 monitors and every one with a different resolution 
and moves a window between all of them, so that it bothers him?


My conclusion is that it really is not worth it to introduce a 
floating-point precision sizes within the LCL. Yes, there would be some 
gain in scaling precision but only for a lot of different DPI values 
(more than 3) and the gain would not be striking. On the other hand, the 
effort needed would be very high, especially due to forwards 
compatibility of the LFM format.


Ondrej

Program code:

program TestScaling;
uses Math, SysUtils;
const
  //DefResolutions: array[0..2] of Double = (1.00, 1.25, 2.00);
  DefResolutions: array[0..4] of Double = (1.00, 1.25, 1.50, 1.75, 2.00);
  //DefResolutions: array[0..8] of Double = (1.00, 1.25, 1.50, 1.75, 
2.00, 2.50, 3.00, 3.50, 4.00); // test even more resolutions - up to 400%
  MaxDiffFromValue = 16; // do not test values smaller than this for 
MaxDiff*
function Scale(const aValue: Integer; const aFromResolution, 
aToResolution: Double): Integer;

begin
  Result := Round(aValue / aFromResolution * aToResolution);
end;
function ScaleCycle(const V: Integer; R: TArray): Integer;
var
  I: Integer;
begin
  Result := V;
  for I := 0 to High(R)-1 do
    Result := Scale(Result, DefResolutions[R[I]], DefResolutions[R[I+1]]);
  Result := Scale(Result, DefResolutions[R[High(R)]], 
DefResolutions[R[0]]);

end;
function NextCombination(var R: TArray): Boolean;
var
  I: Integer;
begin
  for I := High(R) downto 0 do
  begin
    if R[I]): Boolean;
var
  I, L: Integer;
begin
  for I := 0 to High(R) do
    for L := I+1 to High(R) do
  if R[I]=R[L] then
    Exit(False);
  Result := True;
end;
function WriteCombination(const R: TArray): string;
var
  I: Integer;
begin
  Result := '';
  for I := 0 to High(R) do
    Result := Result + IntToStr(R[I]);
end;
function WriteResolutions(const R: array of Double): string;
var
  I: Integer;
begin
  Result := '';
  for I := 0 to High(R) do
  begin
    if Result<>'' then
  Result := Result + ', ';
    Result := Result + IntToStr(Round(R[I]*100))+'%';
  end;
end;
var
  Resolutions: array of Integer;
  I, F, RefValue, Cycle, ResolutionSteps, MaxValue, StartValue, 
MaxDiff, MaxDiffStartValue, MaxDiffEndValue: Integer;

  Count: Int64;
  MaxDiffRatio: Double;
  Errors: array of Int64;
  MaxDiffCombination: string;
  UniqueCombinationsC: Char;
  UniqueCombinations: Boolean;
begin
  try
    Write('Do you want to test only unique combinations? (y/n): ');
    ReadLn(UniqueCombinationsC);
    UniqueCombinations := LowerCase(UniqueCombinationsC)='y';
    if UniqueCombinations 

Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus
Here is a more general proof for every possible combination of 
resolutions between 100% and 400% and for values [0..1]:


program Project1;
uses Math;
const
  Resolutions: array[0..8] of Double = (1.00, 1.25, 1.50, 1.75, 2.00, 
2.50, 3.00, 3.50, 4.00);

var
  SourceResultion, TargetResolution: Double;
  I, F, ErrorCountInMiddleValue, ErrorCountAfterSecondScaling, 
MiddleValue: Integer;

begin
  ErrorCountInMiddleValue := 0;
  ErrorCountAfterSecondScaling := 0;
  for SourceResultion in Resolutions do
    for TargetResolution in Resolutions do
  if not SameValue(SourceResultion, TargetResolution) then
  begin
    for I := 0 to 1 do
    begin
  F := I;
  // scale from source to target and back
  F := Round(F / SourceResultion * TargetResolution);
  F := Round(F * SourceResultion / TargetResolution);
  MiddleValue := F;
  if not SameValue(F, I) then
  begin
    Inc(ErrorCountInMiddleValue);
    // scale from source to target and back again
    F := Round(F / SourceResultion * TargetResolution);
    F := Round(F * SourceResultion / TargetResolution);

    if not SameValue(F, MiddleValue) then
    begin
  Writeln('Error after second scaling: ', I, ': ', F, ' 
SourceResultion:TargetResolution (', SourceResultion, ':', 
TargetResolution, ')');

  Inc(ErrorCountAfterSecondScaling);
    end;
  end;
    end;
  end;
  Writeln('ErrorCountInMiddleValue: ', ErrorCountInMiddleValue);
  Writeln('ErrorCountAfterSecondScaling: ', ErrorCountAfterSecondScaling);
  ReadLn;
end.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus

On 08.06.2023 12:24, Giuliano Colla wrote:


Il 08/06/23 11:58, Ondrej Pokorny via lazarus ha scritto:

All in all, an over-complicated approach with little gain.


The gain would be that you do not add up rounding errors. We can't 
have fractional pixels, of course, but we may have the exact actual 
size at design/creation time, and for each different DPI the best 
approximation to the actual size. If you switch back and forth between 
two monitors with different DPI the rounding errors remain constant, 
they don't add up.


As I showed in my last email, switching back and forth between two 
monitors with different DPI the rounding errors remain constant even 
with the current integer-precision pixel values. The rounding errors 
never add up.


So the problem you want to solve does not exist in the first place.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus

On 08.06.2023 12:24, Giuliano Colla wrote:


Il 08/06/23 11:58, Ondrej Pokorny via lazarus ha scritto:

All in all, an over-complicated approach with little gain.


The gain would be that you do not add up rounding errors. We can't 
have fractional pixels, of course, but we may have the exact actual 
size at design/creation time, and for each different DPI the best 
approximation to the actual size. If you switch back and forth between 
two monitors with different DPI the rounding errors remain constant, 
they don't add up.


You have to consider that for monitor DPI scaling, incrementing series 
of multiplications like

A * 1.5 * 1.25 * 1.75 * 2.00 * etc * etc
never appear.

You always have a limited count of different resolutions (usually 2) and 
you always switch between up- and down-scaling. Statistically the 
Round() function rounds up and down equal sets of float values. So, 
statistically, the errors cannot add up, but they fix themselves up with 
the count of up- and down-scaling operations.


Here is my proof for switching between 2 different resolutions from 
start with 100%:


program Project1;
uses Math;
const
  Resolutions: array[0..3] of Double = (1.25, 1.50, 1.75, 2.00);
var
  R: Double;
  I, F: Integer;
begin
  for R in Resolutions do
    for I := 0 to 1000 do
    begin
  F := I;
  // scale first up and then down
  F := Round(F * R);
  F := Round(F / R);
  if not SameValue(F, I) then
    Writeln(I, ': ', F);
    end;
  ReadLn;
end.

Run the program, and you will se that there is no starting value at 100% 
that would differ if you scale it up and down.


---

If you want to test scaling down and up, then there of course there will 
be a discrepancy between starting and ending value after 1 down- and 
up-scaling cycle because you lose resolution with the first division. 
But if you do the same up/down scaling again, you will see that every 
starting value ended at a well defined pair of values. The values 
definitely do not grow or shrink with the count of scaling operations.


program Project1;
uses Math;
const
  Resolutions: array[0..3] of Double = (1.25, 1.50, 1.75, 2.00);
var
  R: Double;
  I, F, ErrorCountInMiddleValue, ErrorCountAfterSecondScaling, 
MiddleValue: Integer;

begin
  ErrorCountInMiddleValue := 0;
  ErrorCountAfterSecondScaling := 0;
  for R in Resolutions do
    for I := 0 to 1000 do
    begin
  F := I;
  // first scale down, then up
  F := Round(F / R);
  F := Round(F * R);
  MiddleValue := F;
  if not SameValue(F, I) then
  begin
    Inc(ErrorCountInMiddleValue);
    // scale first down and then up
    F := Round(F / R);
    F := Round(F * R);

    if not SameValue(F, MiddleValue) then
    begin
  Writeln('Error after second scaling: ', I, ': ', F);
  Inc(ErrorCountAfterSecondScaling);
    end;
  end;
    end;
  Writeln('ErrorCountInMiddleValue: ', ErrorCountInMiddleValue);
  Writeln('ErrorCountAfterSecondScaling: ', ErrorCountAfterSecondScaling);
  ReadLn;
end.

As you can see, there is no starting value that would cause a constantly 
incrementing or decrementing series of values. Every starting value 
settles down on a well-defined pair of values after the second scaling.


I consider my arguments as proven. Your suggestion to have a better 
precision units for sizes doesn't help at all.


---

And even if you found some very rare combination of scaling A -> B -> C 
-> A of some value X that increments by 1px every time after the whole 
scaling cycle is performed: who cares that after so many scaling 
operations the window/column/... width is bigger/smaller by 1px?
As I said in the beginning, the default values should not be scaled with 
this approach, they should be scaled always from a constant value at 
100%/96 PPI. That means for them the rounding error problem does not 
apply. It would apply only for user-defined sizes and there it does not 
matter because if the size doesn't do it for the user, he can always 
resize the window/column/ whatever.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus

On 08.06.2023 11:46, Giuliano Colla via lazarus wrote:

Il 08/06/2023 11:34, Giuliano Colla via lazarus ha scritto:


Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto:

Check TCustomColorBox how it handles FColorRectWidth as an example 
(it uses a default value and if the user overwrites it, it gets 
scaled in DoAutoAdjustLayout().


I believe that scaling for different DPI has been implemented with a 
shortsighted approach.
IMHO the general approach should have been (or should be if someone 
is willing to face it) to have *two* parameters for width and height: 
a pixel value and a linear value (in mm, inches, whatever).
If the designer or user sets the pixel value, this value is taken and 
used, but the linear value is  calculated.
If the designer or user sets the linear value, the pixel value is 
calculated using the current DPI, and is used to paint the control.
A new DPI will cause all pixel values to be updated from the linear 
values.
I don't know if there are some cases where the pixel value should be 
retained even for a significant DPI change. A FixedPixel boolean or a 
zero value in the linear value might override the resizing.


I understand that this would require a revision of all TControl 
descendants, by exposing the new properties, but I believe it to be 
the only way to make the DPI handling user friendly and mainly 
transparent to the users.


Giuliano



An afterthought. A simpler way (or a first step) could be to keep the 
linear value hidden. This wouldn't require a deep LCL revision, and 
would make fully transparent the DPI handling. The designer sets the 
desired width/height to the current screen, but the linear value is 
stored and used whenever the DPI changes.


Well, this still could be implemented.

But do not forget that the LCL must stay backwards-compatible (old code 
must work in new versions) and to some extend also forwards-compatible 
(LFM from new Lazarus versions must open in older Lazarus versions - 
that is valid for at least 2 latest stable versions). Especially, the 
LFM compatibility is an issue.


All in all, an over-complicated approach with little gain.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-08 Thread Ondrej Pokorny via lazarus

On 08.06.2023 11:34, Giuliano Colla wrote:

Il 08/06/2023 08:08, Ondrej Pokorny via lazarus ha scritto:

Check TCustomColorBox how it handles FColorRectWidth as an example 
(it uses a default value and if the user overwrites it, it gets 
scaled in DoAutoAdjustLayout().


I believe that scaling for different DPI has been implemented with a 
shortsighted approach.
IMHO the general approach should have been (or should be if someone is 
willing to face it) to have *two* parameters for width and height: a 
pixel value and a linear value (in mm, inches, whatever).
If the designer or user sets the pixel value, this value is taken and 
used, but the linear value is  calculated.
If the designer or user sets the linear value, the pixel value is 
calculated using the current DPI, and is used to paint the control.
A new DPI will cause all pixel values to be updated from the linear 
values.
I don't know if there are some cases where the pixel value should be 
retained even for a significant DPI change. A FixedPixel boolean or a 
zero value in the linear value might override the resizing.


I understand that this would require a revision of all TControl 
descendants, by exposing the new properties, but I believe it to be 
the only way to make the DPI handling user friendly and mainly 
transparent to the users.


LOL. What advantage do you get from this approach? You get rid of 
rounding errors when scaling occurs? So you get rid of problems within 
1px margins? And what do you have to pay for it? To double-up all 
current pixel (integer precision) values with other double-precision 
units and do conversions between them all the time? No way it is a 
better approach.


Well, you can create your own component library from scratch that will 
use double-precision units for positions&sizes (Delphi FireMonkey is one 
example). VCL and LCL have been designed when scaling was not an issue, 
so you have to live with the preconditions.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-07 Thread Ondrej Pokorny via lazarus

On 08.06.2023 07:53, Ondrej Pokorny via lazarus wrote:

On 08.06.2023 00:46, Vojtěch Čihák via lazarus wrote:


Because I need to scale internals of TGraphicControl (which has no 
own Canvas or Handle) I decided to do scaling in SetParent();.



You definitely should use DoAutoAdjustLayout().

Usually the best way to do "internals" scaling is to scale them when 
they are needed and not to store the scaled value.


Take a look at this example:
* TToolButton.Paint:
  dist := FToolbar.Scale96ToFont(cHorIconTextDist);

The following examples show you how to handle a scaled internal value 
with a default value

* TCustomColorBox.ColorRectWidth
* TCustomGrid.DefaultColWidth
* TCustomTreeView.ExpandSignSize

---

If you have values that need to be scaled you do:

1.) Initialize the sizes for Screen.PixelsPerInch in constructor:
MySize := Scale96ToScreen(cMyValueAt96DPI);

2.) Use DoAutoAdjustLayout() to scale them when PPI changes:
MySize := Round(MySize * AXProportion);

Simple as that.

Check TCustomColorBox how it handles FColorRectWidth as an example (it 
uses a default value and if the user overwrites it, it gets scaled in 
DoAutoAdjustLayout().


Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-07 Thread Ondrej Pokorny via lazarus

On 08.06.2023 00:46, Vojtěch Čihák via lazarus wrote:


Thanks,

please confirm me if I understand well the concept:

1) when component is put on the form in designer: it is scaled (Width 
& Height)



Yes.


2) when it is put on the form later in code: it is not scaled


It depends on what you understand with "it is not scaled".

If you do:

MyComponent.Parent := Panel1;
MyComponent.Width := 100;
MyComponent.Height := 100;

Then obviously the width/height is not scaled because you assigned 
constant numbers there.


But the internals are scaled with DoAutoAdjustLayout() if the target PPI 
(of Panel1) is different from Screen.PixelsPerInch.



but internals are scaled in both cases (by internals I mean for 
example DefaultRowHeight and DefaultColWidth of TStringGrid)


Or at least TStringGrid behaves as I described above.


Yes.


Because I need to scale internals of TGraphicControl (which has no own 
Canvas or Handle) I decided to do scaling in SetParent();.



You definitely should use DoAutoAdjustLayout().


For curiosity: was tested the case when someone has two or more 
monitors with different DPI and moves the form (made in Lazarus) from 
one monitor to another?



Yes. DoAutoAdjustLayout() takes care of it.

Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hi-DPI tweak of components

2023-06-06 Thread Ondrej Pokorny via lazarus

On 07.06.2023 00:35, Vojtěch Čihák via lazarus wrote:


I finally built a hi-DPI machine (28'' 4k display, currently set to 
118PPI) and I need to tweak EC-Controls 
(https://wiki.freepascal.org/Eye-Candy_Controls) to scale better.


One problematic is TECSpinBtns because it is designed like this: it 
consists of (initially) nine small buttons (TPersistent) with 
hardcoded width=15 and its overall width is 9*15 =135 pixels or N*15 
in general.


Therefore, when I put this component on the form, its Width is not 
scaled (Height is). I tried to override DoAutoAdjustLayout but it's 
not triggered at all.


TECSpinBtns is TGraphicControl.

Here is information: 
https://wiki.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.8_and_above


IIRC, DoAutoAdjustLayout() is executed only when the DPI changes. You 
have to scale every hardcoded pixel value in the 
constructor/loading/intitialize as well.


Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Resources without RC files

2023-05-04 Thread Ondrej Pokorny via lazarus

On 04.05.2023 11:02, Michael Van Canneyt wrote:

On Thu, 4 May 2023, Ondrej Pokorny wrote:

On 04.05.2023 08:38, Michael Van Canneyt wrote:

On Thu, 4 May 2023, Ondrej Pokorny via lazarus wrote:
How is it possible that the LFM files are included directly but 
*.SQL files are parsed as RC files?


Because the file extension is recognized ? LFM is included as 
RC_DATA, and probably everything that is not .lfm is assumed to be a 
RC format.


I believe fpcres also has this check.


Thanks for the tip. I found it - it is directly in the compiler.

In comprsrc.pas TWinLikeResourceFile.IsCompiled there is a logic that 
defines what the compiler does with the included resource file based 
on the extension or file header.


I don't like the fact that there are hard-coded constants for what 
seems to be (for a stranger) arbitrary file extensions and that it is 
not documented anywhere.


Well, developers that are using lazarus and form files know what happens.

This is undoubtedly the majority of FPC users, so I don't think this 
is an

issue.


It is still confusing - in pas2js any file can be added as a resource with:

{$R abc.xyz}

In FPC only LFM, so hence the question why and how :)

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Resources without RC files

2023-05-04 Thread Ondrej Pokorny via lazarus

On 04.05.2023 08:38, Michael Van Canneyt wrote:

On Thu, 4 May 2023, Ondrej Pokorny via lazarus wrote:
How is it possible that the LFM files are included directly but *.SQL 
files are parsed as RC files?


Because the file extension is recognized ? LFM is included as RC_DATA, 
and probably everything that is not .lfm is assumed to be a RC format.


I believe fpcres also has this check.


Thanks for the tip. I found it - it is directly in the compiler.

In comprsrc.pas TWinLikeResourceFile.IsCompiled there is a logic that 
defines what the compiler does with the included resource file based on 
the extension or file header.


I don't like the fact that there are hard-coded constants for what seems 
to be (for a stranger) arbitrary file extensions and that it is not 
documented anywhere.


I will raise the question in the FPC mailing list.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] Resources without RC files

2023-05-03 Thread Ondrej Pokorny via lazarus

Hello,

I see that the LCL includes LFM files as resources directly without a 
*.RC file:


{$R *.lfm}

---

But if I do this with my custom file. E.g.:

{$R *.sql}

I get an "error when compiling resources":

Compile Project, Mode: Debug, Target: Test.exe: Exit code 1, Errors: 1, 
Warnings: 1

Warning: windres: can't open file `REPLACE': No such file or directory
uTest.pas(96,0) Error: Error while compiling resources -> Compile with 
-vd for more details. Check for duplicates.


---

How is it possible that the LFM files are included directly but *.SQL 
files are parsed as RC files?


---

I checked the Wiki and Docs, but didn't find any information about it:

https://wiki.freepascal.org/Lazarus_Resources
https://www.freepascal.org/docs-html/prog/progsu67.html#x74-730001.2.67

Thanks
Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Can older Lazarus use newer FPC?

2023-03-29 Thread Ondrej Pokorny via lazarus

On 28.03.2023 13:52, Bo Berglund via lazarus wrote:

Can these be changed to point to the new FPC so the old FPC is no longer needed?


Usually yes, FPC usually is backwards compatible. But there can be some 
glitches. I would update Lazarus along with FPC a well.


Anyway, you can always check if everything works with the new FPC 
version and if yes, only then delete the old FPC version.


Ondrej


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Screwed up Lazarus installation - how to make clean and start over?

2023-02-22 Thread Ondrej Pokorny via lazarus

On 22.02.2023 18:01, Bo Berglund via lazarus wrote:

On Wed, 22 Feb 2023 10:43:35 +0100, Bo Berglund via lazarus
 wrote:


Lacking any advice here I started over by removing the old Lazarus directory and
the pcp dir and then build from start with a new set of source files in a fresh
2.2.4 subdir...

All was Ok until again the OLPM packages were installed when the new Lazarus
also failed to start. It seems like at least one of the packages I use from OLPM
will hose Lazarus!

So now I will repeat the effort but this time I will install one package after
another using OLPM and rebuild Lazarus IDE after each. This way I would be able
to pinpoint the one that causes the problem.

So now I have found a package in OnLinePackageManager that will hose Lazarus if
installed:
  BGRABitmap

Up until installing that I was fine, but now Lazarus won't start

The Initial image is shown for 3 seconds and then disappears.
Then nothing...

What can I do to get into Lazarus and remove the BGRABitmap?

Or is there somewhere a file or such I can edit and then rebuild the IDE from
the command line?

This is on Linux (Raspberry Pi  OS).


Usually there is an "old" Lazarus executable (lazarus.old) next to the 
Lazarus executable. I usually switch to that if something is wrong with 
the new one. A problem arises if the old exe doesn't work either because 
it has been overwritten etc. Try it, that might be the quickest help.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] vanishing main menu wanted

2023-01-08 Thread Ondrej Pokorny via lazarus

On 08.01.2023 10:13, duilio foschi via lazarus wrote:

Which is the best way to get this effect?


Probably TToolBar.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Error building Lazarus Trunk

2023-01-01 Thread Ondrej Pokorny via lazarus

Am 01.01.2023 um 3:48 schrieb Wayne Sherman:

Ondrej Pokorny wrote:
Please update and retest. It should be fixed.

Sorry, getting the same error:


Ok , 2nd attempt :)

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/71ac105bc728824b849c027a016ad572226002c1

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Error building Lazarus Trunk

2022-12-31 Thread Ondrej Pokorny via lazarus

Am 01.01.2023 um 2:29 schrieb Wayne Sherman via lazarus:

System Xubuntu 20.04 64-bit with latest updates

lazarus_2_2_4 (latest stable) builds successfully, but I am getting an
error trying to build Lazarus trunk.  The same error happens with both
fpc stable and fpc trunk.

Running this:

git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git
2022-12-31_lazarus_trunk
cd ./2022-12-31_lazarus_trunk

make distclean [ok]
make lazbuild  [ok]
make bigide [ok]

make useride  [fails]
./lazbuild --lazarusdir=. --build-ide=  [fails]

Build messages:
Hint: (lazarus) Missing state file of DebuggerIntf 0.1:
/home/wsherman/2022-12-31_lazarus_trunk/components/debuggerintf/lib/x86_64-linux/DebuggerIntf.compiled
An unhandled exception occurred at $009B6FB0:
EAccessViolation: Access violation
   $009B6FB0  DOCALLPACKAGEBUILDINGHANDLER,  line 774 of lazideintf.pas
   $005AFCAA  COMPILEPACKAGE,  line 4265 of 
../packager/packagesystem.pas
   $005AE928  COMPILEREQUIREDPACKAGES,  line 3972 of
../packager/packagesystem.pas
   $0040366A  COMPILEAUTOINSTALLPACKAGES,  line 683 of lazbuild.lpr
   $004032A9  BUILDLAZARUSIDE,  line 621 of lazbuild.lpr
   $0040817F  RUN,  line 1503 of lazbuild.lpr
   $0040AA09  main,  line 1879 of lazbuild.lpr

There appears to be two problems:
1) Some state is not as lazbuild expects.
2) lazbuild should not generate an access violation.

Can anyone confirm this issue?


Please update and retest. It should be fixed.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LCL compilation fail for at least x86_linux

2022-12-17 Thread Ondrej Pokorny via lazarus

Am 17.12.2022 um 18:46 schrieb Marcus Sackrow via lazarus:

Hi,

Am 17.12.22 um 18:25 schrieb Marco van de Voort via lazarus:


On 17-12-2022 17:49, John Landmesser via lazarus wrote:


Lazarus 2.3.0 (rev main-2_3-2521-gb4c46c) FPC 3.2.2
x86_64-linux-gtk2

So lazarus just compiles fine ...


Copying a bunch of base types to uitypes has been committed to FPC
trunk.  Marcus is probably using trunk.

Merging this to 3.2.4 is under debate. I favour merging it back to
fixes, to keep the transition period as short as possible, since major
releases are even slower to emerge than pointreleases.


yes it is trunk, thats the second meaning of this jenkins compilation
because sometimes FPC fails only appear when compiling other sources
(like LCL)

and yes If I look more careful to, the compilatino was triggered by this
change in FPC

https://gitlab.com/freepascal.org/fpc/source/-/commit/d1616cb0d1210c44ab76807346e10dcba9ab6a63


Yes, sorry, I forgot to commit the Lazarus part of the patch yesterday.

It should be OK now.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] pas2js and server sent events

2022-08-26 Thread Ondrej Pokorny via lazarus

Hello Luca,

better send the message to pas2js mailing list directly: 
https://lists.freepascal.org/mailman/listinfo/pas2js/


Ondrej


Am 26.08.2022 um 09:16 schrieb Luca Olivetti via lazarus:

Hello,

I see that pas2js has support for websockets, but I cannot find if it 
also supports server sent events.


A couple of years ago I implemented an application with sse where I 
used fpWeb and plain html+javascript in the browser.


Now I need to implement a more complex application and I'd like to use 
pas2js, if it supports sse I can reuse the old server class, if it 
doesn't I'll have to reimplement it as a websocket server.



Bye

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Strange issue with TImage and lazarus 2.2.2

2022-06-30 Thread Ondrej Pokorny via lazarus

On 30.06.2022 18:20, Werner Pamler via lazarus wrote:

Am 30.06.2022 um 17:03 schrieb Ondrej Pokorny via lazarus:

On 30.06.2022 16:54, Werner Pamler via lazarus wrote:

Am 30.06.2022 um 15:11 schrieb Mattias Gaertner via lazarus:

Maybe instead of the GraphicClass.ClassName the first extension can be
written.
That means, that an old IDE cannot read the graphic.
This will break Delphi compatibility, i.e. forms with an image in 
which the Picture has been loaded by Delphi will not be readable by 
Lazarus any more, and vice versa. Just checked again the signature 
that Delphi writes to the begin of the Picture.Data: it's the class 
name, not the extension.


And what about writing the extension to the data end?

    Picture.Data = {
  0B 54 49 6D 61 67 69 6E 67 50 4E 47 89 50 4E 47 0D 0A 1A 0A 00 
00 00 0D 49 48 44 52 00 00 01 C6
  11 T  I  m  a  g  i  n  g  P  N  G    // 11 is the 
length byte

  03 p  n  g

That should be both Delphi and legacy Lazarus compatible if the 
reader reads only the defined count of bytes for the classname?


But isn't this the same problem? When Vampyre is not installed, and 
the streamer sees the TImageingPNG classname there is no way how to 
find the end of the Picture.Data block.


Oh yes, you are right. The ClassName is written in the beginning of the 
stream. From the sample I assumed it is written in the end but that 
doesn't make sense. My bad.


---

Well there is an easier solution. I just remembered that I added an 
image handler resolver TFPCustomImage.FindHandlerFromStream() to FPC 
three years ago: https://gitlab.com/freepascal.org/fpc/source/-/issues/33955


So if the ClassName is not found, the FP image handler can be found from 
the actual image stream. Every image format can be detected directly 
from the stream, so the ClassName is actually redundant. When we have 
the TIHData for the stream, then we have everything - the extension and 
the FP reader/writer. From this information we can find the LCL image 
handler from the registered list - of course only if at least /some/ 
handler is registered for the extension.


Of course, we are limited to the FPC version - I don't know if the 
feature is already in a released version. But we can add the support for 
the FPC versions with this feature.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Strange issue with TImage and lazarus 2.2.2

2022-06-30 Thread Ondrej Pokorny via lazarus

On 30.06.2022 16:54, Werner Pamler via lazarus wrote:

Am 30.06.2022 um 15:11 schrieb Mattias Gaertner via lazarus:

Maybe instead of the GraphicClass.ClassName the first extension can be
written.
That means, that an old IDE cannot read the graphic.
This will break Delphi compatibility, i.e. forms with an image in 
which the Picture has been loaded by Delphi will not be readable by 
Lazarus any more, and vice versa. Just checked again the signature 
that Delphi writes to the begin of the Picture.Data: it's the class 
name, not the extension.


And what about writing the extension to the data end?

    Picture.Data = {
  0B 54 49 6D 61 67 69 6E 67 50 4E 47 89 50 4E 47 0D 0A 1A 0A 00 00 
00 0D 49 48 44 52 00 00 01 C6
  11 T  I  m  a  g  i  n  g  P  N  G    // 11 is the 
length byte

  03 p  n  g

That should be both Delphi and legacy Lazarus compatible if the reader 
reads only the defined count of bytes for the classname?


Newer Lazarus versions would first search the extension and if not found 
they search for the classname.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Strange issue with TImage and lazarus 2.2.2

2022-06-30 Thread Ondrej Pokorny via lazarus

On 30.06.2022 15:11, Mattias Gaertner via lazarus wrote:

On Fri, 24 Jun 2022 17:27:13 +0200
Werner Pamler via lazarus  wrote:


[...]
But still the situation is not very satisfying.

Maybe instead of the GraphicClass.ClassName the first extension can be
written.
That means, that an old IDE cannot read the graphic.


I did this already before: the next stable release should write the 
ClassName but support reading the extension and then the second stable 
release should write the extension.


With it we make sure that always the last 2 released version can read 
the LFM. That is enough.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus is running but not responding.

2022-04-25 Thread Ondrej Pokorny via lazarus

On 22.04.2022 20:38, Mattias Gaertner via lazarus wrote:

On Fri, 22 Apr 2022 14:47:14 +0200
Martin Frb via lazarus  wrote:


[...]
It's also very annoying, if you have a hanging IDE instance. It is
impossible to start a 2nd instance to attach and debug.

lazarus.exe --force-new-instance


Yes, it is annoying. I'll improve it.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus is running but not responding.

2022-04-21 Thread Ondrej Pokorny via lazarus

On 21.04.2022 12:05, Michael Van Canneyt via lazarus wrote:

On Thu, 21 Apr 2022, Michael Van Canneyt via lazarus wrote:
Restarting the PC is NOT an option at this point, and won't be for 
the next

couple of hours...

Where are these files located ?


OK. Found it, they are in /tmp/*LazarusMain*

Well, this is definitely something that can be improved :-)


Yes, definitely. I will note it down again. It bugs me as well.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus is running but not responding.

2022-04-21 Thread Ondrej Pokorny via lazarus

On 21.04.2022 11:36, Michael Van Canneyt via lazarus wrote:

Lazarus was completely stuck under high load.

No way to close it. I had to kill Lazarus with

killall -KILL lazarus

When I then attempted to restart lazarus, I got "Lazarus is running 
but not responding."

(see screenshot)

I have not found a way to start it again.

So, what should I do now ?


It means that the IPC files are still blocked. Please restart your PC 
and write back if it didn't help.


This Lazarus part is something I am not really proud of and should be 
rewritten...


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Component palette enhancements

2022-04-12 Thread Ondrej Pokorny via lazarus
I have used the "Components" window in a non-docked environment with no 
problems. I removed the component palette altogether. IMO the point is 
to use it as a dialog, not as a constantly open IDE window.


My workflow is: open the Components window with a keyboard shortcut, 
find the component by typing, place the component where wanted with a 
mouse-click, close the window.


That brings me to the 2 issues I found:

1.) I used to open the Components window with Ctrl+Alt+P. I have a 
short-cut associated with it (see the attachment). But the shortcut is 
not recognized (I press Ctrl+Alt+P and it does nothing). It looks like 
an application-wide problem. The shortcut is not recognized in the 
"Choose a key..." dialog in IDE Options -> Key Mappings either.


Strange is that Ctrl+Alt+D (show desktops) works fine. Maybe it is just 
my PC that eats the Ctrl+Alt+P shortcut? Can anybody confirm? I am on 
Windows 10.


2.) When the "Keep open" checkbox is unchecked and I single-click on a 
component to select it and place it with a mouse click on the form (no 
double-click), the Components window is not closed.


Is it wanted? Shouldn't be the window closed?

Thanks
Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Component icons howto ?

2022-03-30 Thread Ondrej Pokorny via lazarus

On 30.03.2022 10:44, Michael Van Canneyt via lazarus wrote:

On Wed, 30 Mar 2022, Arne Hanssen via lazarus wrote:

Den 30.03.2022 09:57, skreiv Michael Van Canneyt via lazarus:


[...]

Why do you think I know this is a scaling factor ?

I didn't have a clue until Werner explained.

Sorry, you can argue all you like, but if I see a list of icon files 
xyz_24x24.png then I know *exactly* what to create, just from the 
filenames. No need to do math, open file whatnot.


With your method, I need to open the file (unless I know standard 
size is
24), check the size, and then possibly multiply (if I know that the 
suffix

is the scaling factor in %).

[...]

I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) 
could be a reasonable naming solution?


As I said: 150, 200 do not strike me as scalings in percent.

That the CPU needs to do an extra couple of cycles (convert scaling to
pixel) to make things easier on humans - that's why mankind invented it.

Forgive me, but I will discontinue the discussion.

I think I made it clear what I think is (in my view) absurd and have 
no wish

to antagonize anyone by continuing to argue for something which should be
obvious and plain.


I don't think anybody took this personal - definitely not myself. But I 
still don't know what you intended with the discussion. The naming 
convention has been like this for 5 years - I introduced it in this 
commit 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/2135d3058f078e3df8b957c4fa4e52e1fa1ae83b


We now tried to explain the reasoning behind it - I honestly did not 
care that much about the naming convention back then: I just took what 
was the simplest way from my POV - simplest to extend the existing code 
and the existing directory and file structure. I concentrated much more 
on the scaling system behind it as it was quite a monster of a change. I 
do admit that I did not think about the icon creators on the other side 
at all - so I missed what you see is "obvious and plain". Sorry for that 
but what should I do with it now?


If somebody (including you) had raised the discussion about the (not 
obvious) naming back then before hundreds of icons were added, it would 
have been a much easier change than today. But there was no such 
discussion (no alternative was either suggested or rejected), so we 
ended up with the solution that I picked up. There were no bad 
intentions from my side, I just decided somehow and nobody has 
complained about it for 5 years. That's all about it.


I now cannot do a lot about a 5-year-old decision. Yes, it may have been 
wrong, but I am not going to rename all the files added in the meantime 
by myself...


Yes, we can still extend the code to support Delphi's naming convention. 
But as Werner stated before, we won't rename current icons ourselves. If 
you want to take the effort because you think it is worth it and Werner 
is not against, go for it. I personally don't think it is worth it.


In the end it's just about file names, the result is the same: the user 
sees pixel-perfect icons and the IDE scales nicely. A different naming 
convention won't improve that.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Component icons howto ?

2022-03-30 Thread Ondrej Pokorny via lazarus

On 30.03.2022 10:20, Arne Hanssen via lazarus wrote:
I would guess that naming the files 'xyz_24x24.png' (base size 24px), 
'xyz_24x24_150.png' (150% 36px) and 'xyz_24x24_200.png' (200% 48px) 
could be a reasonable naming solution?


On the contrary: it is the bad from both naming solutions :)

You need to know both the scaling factor and the size.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Component icons howto ?

2022-03-30 Thread Ondrej Pokorny via lazarus

On 30.03.2022 09:57, Michael Van Canneyt via lazarus wrote:

On Wed, 30 Mar 2022, Ondrej Pokorny via lazarus wrote:

On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:

On Tue, 29 Mar 2022, Werner Pamler wrote:
I don't know the actual procedure names ATM, but imagine that when 
the message window needs a "warning" icon (which is - say - 12x12 
at 96ppi) then the scaling procedure at 192ppi only needs to look 
for "warning_200.png". If the exact image size would have been 
included in the file name instead ("warning_24x24.png"), it would 
have to know the size of the base image at 96ppi in order to select 
the right image. A little simplification.


I fail to see the link between 192 and 200. This requires people to 
know
that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a 
standard size.


Forget about the DPI/PPI values. What you need is the %-scaling 
factor of the original size.


Why do you think I know this is a scaling factor ?

I didn't have a clue until Werner explained.

Sorry, you can argue all you like, but if I see a list of icon files 
xyz_24x24.png then I know *exactly* what to create, just from the 
filenames. No need to do math, open file whatnot.


With your method, I need to open the file (unless I know standard size is
24), check the size, and then possibly multiply (if I know that the 
suffix

is the scaling factor in %).

As it was, I actually opened 3 files to see what the needed sizes were.

By contrast, if I need to create icons for a Linux app I check e.g:


ls /usr/share/icons/gnome/
128x128/  16x16/  22x22/  24x24/  256x256/  32x32/  48x48/ 512x512/  
64x64/  8x8/  icon-theme.cache  index.theme  scalable/


and I know exactly what to create, just from the names.

If you think that your method is easier, we have very different 
concepts of what is 'easy'.


Well, the difference is the point-of-view and not the concept. My 
point-of-view is the Lazarus IDE developer. Yours is the user.
Mine is easier from the Lazarus development POV, yours is from the 
user's POV.




Clearly, I would not be asking these questions if it was so obvious.


Once you get to know what the postfixes mean, I think it is obvious. I 
agree that it is not obvious per se and having the size in the file name 
is more obvious and easier for the user. Having said that, both methods 
would have to be documented, so after reading the docs both methods 
should be equally clear and easy.


When I worked at the high-DPI Lazarus IDE, I picked up the more obvious 
and easier way for the Lazarus IDE development.


I mainly didn't want to bother with these questions about legacy icons: 
what do you do with the icons "abc.png" (11x11px) and "def.png" 
(16x16px) - do you rename them[?], what do you do with 3rd party IDE 
extensions and packages that supply such icons and Lazarus doesn't have 
control over them etc etc? With the "_150" and "_200" I did not have to 
solve these issues. With yours I did have to solve them indeed.


I am not saying your concept is wrong, I just try to explain the 
reasoning about the concept with scaling postfixes.


Of course all the issues above exist just due to the fact that the IDE 
uses different icon sizes and to keep things simple I decided to have 
the same naming convention for both IDE icons and component icons.


---

I am not against extending the component icon loading to handle a 
different file name convention. As Delphi uses the same concept that you 
prefer https://blogs.embarcadero.com/new-in-10-2-2-component-icons/ , if 
the Lazarus code should be extended then definitely to support the 
Delphi way:


RCDATA TLabel32_PNG "tlabel32.png"

The resource name is the component class name plus the px-value postfix 
(16, 24, 32, ...) and "_PNG" in case of a png file.


Yes, I am absolutely OK with it as an alternative naming convention for 
the component palette because we probably do not want to give up the 
current naming convention due to the effort needed for renaming all the 
files and due to legacy compatibility. But if others agree and somebody 
is willing to take the maintenance effort, we could also deprecate the 
current naming convention and remove it in the 2nd-to-come stable version.


Lazarus had the High-DPI support before Delphi so there was no chance 
for us to know what Delphi would eventually choose, so having the 
Delphi-convention as an alternative was inevitable anyway.


---

I am not sure about the IDE icons, though - due to the issues regarding 
different icon sizes. But if you have a solution for these issues, you 
can definitely implement it as well.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Component icons howto ?

2022-03-30 Thread Ondrej Pokorny via lazarus

On 29.03.2022 19:45, Michael Van Canneyt via lazarus wrote:

On Tue, 29 Mar 2022, Werner Pamler wrote:
I don't know the actual procedure names ATM, but imagine that when 
the message window needs a "warning" icon (which is - say - 12x12 at 
96ppi) then the scaling procedure at 192ppi only needs to look for 
"warning_200.png". If the exact image size would have been included 
in the file name instead ("warning_24x24.png"), it would have to know 
the size of the base image at 96ppi in order to select the right 
image. A little simplification.


I fail to see the link between 192 and 200. This requires people to know
that 96dpi and 144 dpi and 192 dpi are 100, 150 and 200 % of a 
standard size.


Forget about the DPI/PPI values. What you need is the %-scaling factor 
of the original size.




For me - and I've been in IT for quite some time now - this is far from
obvious that this should result in 24x24, 36x36 and 48x48 icon sizes.


What?

100% => 24px - that is the usual and recommended size for component 
palette icons at 100% scaling - e.g. Delphi uses the same size for the 
component icons. Take it as a starting point.

150% => 24px * 150 / 100 = 36px
200% => 24px * 200 / 100 = 48px

That should be obvious for everybody who knows basic math :)



In short: I think this is a horribly contorted scheme.

All other systems I came across simply use icon dimensions in the 
name. Far simpler and hence preferable in my opinion.


I don't think so. Let me explain:

1.) One reason is legacy&compatibility. Before the High-DPI stuff, all 
the IDE icons did not have the size in the name. Having the icon size in 
px in the name would require a bigger rewrite of Lazarus code than it 
was necessary for the scaling-postfixes and without any gain (see [2] 
below).


There are various places where icons with different sizes are used: tool 
bars (16px), code editor (11px), component palette (24px). All these 
icons did not have the size in the name originally.


2.) The second reason and the main advantage is that Lazarus doesn't 
[need to] know what size of the icon is supplied at a specific scaling 
(even at 100%). The icon sizes are not strictly defined.


The file naming convention is: the original variants (at 100%) do not 
have a postfix, the scaled variants have a postfix with the scaling 
factor in % based on the original icon => you open Lazarus on a screen 
with 150% scaling, Lazarus automatically picks up the icons with "_150" 
postfix. If not found, it scales the original ones automatically. Easy.


Having the size in the file name means that every function that requests 
an icon would have to know the resulting px-size it looks for. That is 
not wanted due to:


2.a) Rounding problems: do you round 11*150%=16.5 to 16px or 17px? You 
would have to consider the same rounding both in the Lazarus code and in 
the graphics editor. Currently only the graphics editor decides about 
the best size of the scaled icon and Lazarus can cope with the undefined 
icon size.


2.b) unwanted fixed icon size: there can be icons at 100% with 16px and 
at 200% with 30px, if the graphics designer decided so. Lazarus will 
take the 30px icons without any issues.


Or, if somebody now decides that the 11px code editor icons need a 
redesign and the new icons will have a base size of 12px instead of 
11px, there is no need to change anything in the code. Lazarus will cope 
with the new size of the icons unless the new size is a complete nonsense.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus build fails

2022-01-25 Thread Ondrej Pokorny via lazarus

I had the same problem and I got this nice answer from Martin:

On 18.01.2022 14:19, Martin Frb wrote:

From within the IDE => New package have been added:
- Once you have a new IDE, that new IDE will include them.
- But an old IDE does not know to include them (Because IDE packages, 
are added to the source code in packager, and therefore are only seen 
after building)


This conflicts happens each time, a new "core" dependency is added.

2 Options:
(In either case make sure to have the very latest from git)

1) make bigide

2) Open the packages 
components/lazdebuggers/lazdebuggerintf/lazdebuggerintf.lpk  and 
ide/packages/idedebugger/idedebugger.lpk

"Install" them to your ide. The do a clean build.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 30.11.2021 00:27, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


On 29.11.2021 17:18, Juha Manninen via lazarus wrote:

The commit message is not perfect but the committed code is, now
that I fully understand the issue.


That is nonsense. I reverted your change. The code user code is
just plain wrong and your change in TFrame doesn't change anything
about it.

No, the code is valid although not recommended. Accessing Canvas 
outside Paint works with some widgetsets and then an exception is wrong.


No, Juha, you don't understand the issue at all.

Accessing Canvas outside Paint is OK under all widgetsets if done 
correctly. Whenever you access the canvas for text measuring you have to 
make sure you can do so. There are 2 solutions for it:


1.) Check HandleAllocated and skip the measurements if the handle is not 
allocated. Like here: 
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/6e5e5b67df9d26cd477588a27029c8007d08add2


- or -

2.) If you really have to do the measurements and return something, 
create an extra handle for the canvas like in TCustomLabel.CalculateSize.


---

The LCL's function is not to force creating the canvas when it cannot be 
naturally created with manipulating itself like you did.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


There are many scenarios when the Canvas cannot be accessed and it
is a
common mistake to access it when not allowed.

I didn't study the issue further but to me it looks strange that
setting
some parameters in CreateParams helps with it. Juha, your commit
description "Somehow fixes issue ..." doesn't help to understand your
change either.


The commit message is not perfect but the committed code is, now that 
I fully understand the issue.


That is nonsense. I reverted your change. The code user code is just 
plain wrong and your change in TFrame doesn't change anything about it.


Try e.g. :

procedure TForm1.Button1Click(Sender: TObject);
var
  grid: TNewGrid;
begin
  grid := TNewGrid.Create(Self);
  grid.MyProperty := 1; // exception
end;

Btw. Delphi behaves the same.

Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 21:09, Ondrej Pokorny via lazarus wrote:


It's basically a very bad idea to force create the handle when the 
component is loaded (that is what you do when you access the canvas).


Check TCustomLabel.CalculateSize in lcl\include\customlabel.inc for the 
solution how to solve this problem correctly in the component's code 
without any modifications needed in T(Custom)Form or T(Custom)Frame.


There, the GetDC(0) is used for Canvas.Handle, so that the label's 
parent's handle doesn't need to be created.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 17:47, Martin Frb via lazarus wrote:

On 29/11/2021 17:18, Juha Manninen via lazarus wrote:


It allows a Frame to stand without a parent in the designer or even 
at runtime in some hypothetical situation(?).
Using Canvas outside Paint may not be recommended but it can be done 
in some widgetsets. The component's duty is to not crash in designer 
or anywhere else when it happens.




I suspect in the Designer it does not stand alone => The designer is 
the parent. But I have not checked.


Unless you have installed the docked designer package (I don't know in 
what shape it is now, AFAIR Michl has done some improvements), the 
designer form is standalone and the frame as well (=they don't have a 
parent).


I assume the IDE designer sets the needed window parameters for the 
frame at some place between loading and showing the frame. But I haven't 
checked now and it's been a while when I fiddled with the designer code 
the last time.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 17:18, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 1:32 PM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


There are many scenarios when the Canvas cannot be accessed and it
is a
common mistake to access it when not allowed.

I didn't study the issue further but to me it looks strange that
setting
some parameters in CreateParams helps with it. Juha, your commit
description "Somehow fixes issue ..." doesn't help to understand your
change either.


The commit message is not perfect but the committed code is, now that 
I fully understand the issue.
CreateParams for Frame now follows the same logic as CreateParams for 
Form.


Frame is not a form.


It allows a Frame to stand without a parent in the designer or even at 
runtime in some hypothetical situation(?).


We definitely should't do anything with the parameters at runtime and 
don't allow frames to be shown as forms by default. What buttons 
(min/max/close/...) should be shown, what border style wtc etc? If the 
programmer wants to show his frame as a standalone form, he can override 
CreateParams() on his own.



Using Canvas outside Paint may not be recommended but it can be done 
in some widgetsets. The component's duty is to not crash in designer 
or anywhere else when it happens.


Well, if the programmer writes his code so that it crashes, what do you 
want to do with it?


Yes, we should handle exceptions in the designer. But your code doesn't 
improve this.




So I would encourage the component author to rewrite his code.


Rewrite? Ok, then TCustomForm must be rewritten, too. They now follow 
the same logic, at least regarding CreateParams().


Rewrite his code = the custom component, not TFrame, not TCustomForm.

It's basically a very bad idea to force create the handle when the 
component is loaded (that is what you do when you access the canvas).


Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 12:32, Michael Van Canneyt via lazarus wrote:

On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:

On 29/11/2021 12:05, Michael Van Canneyt via lazarus wrote:


What do you mean 'artificial restrictions' ?  The above is quite 
standard.


IMHO  "if csLoading" tests are also "quite standard"

"If HandleCreated" exist too, not sure how widespread

"accessing canvas"  outside paint, is discouraged.


Well, as I understood it, painting code will not work on Mac outside the
paint event, so only using canvas inside paint should be standard ?


You can still use the Canvas outside Paint for measuring. But not for 
painting. Painting outside Paint on Windows it is problematic as well.


The "use the Canvas outside Paint for measuring" is valid of course only 
as long as Canvas is there or can be created - and it can be created 
when the handle is created or can be created. And a (normal) control's 
handle can be created only when a parent is set.


That is the problem - the code tries to access canvas when the control's 
handle cannot be created.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TFrame improvements

2021-11-29 Thread Ondrej Pokorny via lazarus

On 29.11.2021 11:32, Martin Frb via lazarus wrote:

On 29/11/2021 10:52, Juha Manninen via lazarus wrote:

Please everybody test issue:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/25124
Some components caused an error when placed on a Frame. Now it 
apparently works.

Can somebody please explain why it works. (See my comment there).



So maybe your patch should be extended, to only do that, if the 
control is in "designtime" state?


Yes, definitely add a condition to check the designtime state.

There are many scenarios when the Canvas cannot be accessed and it is a 
common mistake to access it when not allowed.


I didn't study the issue further but to me it looks strange that setting 
some parameters in CreateParams helps with it. Juha, your commit 
description "Somehow fixes issue ..." doesn't help to understand your 
change either.


So I would encourage the component author to rewrite his code.

Ondrej


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] The "Use" button in Component List

2021-06-28 Thread Ondrej Pokorny via lazarus

On 28.06.2021 13:45, Michael Van Canneyt via lazarus wrote:

On Mon, 28 Jun 2021, Juha Manninen via lazarus wrote:


The list opens with Ctrl-Alt-P and is an alternative to the Component
Palette.
Is the "Use" button somehow useful?
A component can be added by selecting it and clicking on designer, or by
double-clicking it.
The behavior was slightly changed in r64929, issue:
https://bugs.freepascal.org/view.php?id=38706
Now the "Use" button inserts a component at coord(0,0) right away, 
which is

the double-click behavior.
Should the button be removed?


I don't think you should remove it. The fact that you can/must double 
click is not immediatly clear. A button has a clear meaning.


Yes, there is no need to delete it. If you remove it, you even cannot 
make the window smaller (you have the "keep open" checkbox there). And 
as Michael stated - the button makes it clear that you can press Enter 
to  the component.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus Release 2.0.12

2021-02-24 Thread Ondrej Pokorny via lazarus

On 24.02.2021 12:09, Mattias Gaertner via lazarus wrote:

The Lazarus team is glad to announce the release of Lazarus 2.0.12.


Thank you all for your work!

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Change of lfm files

2021-01-26 Thread Ondrej Pokorny via lazarus


On 26.01.2021 10:02, Ondrej Pokorny via lazarus wrote:

On 26.01.2021 09:31, Andrey Sobol via lazarus wrote:

Hello,
Let us suppose, I have changed a form inside tool/debugserver
I see what inside .lfm file a version of LCL changed  from 1.3 to 
2.10 for example.


What is policy about LCL compatibility for patches?
Where can I read about this?


We somehow internally agreed on forwards compatibility for 1 legacy 
version.


That means that LFM created in the latest stable Lazarus version 
should open in the stable version prior to it.


For development it means that 2.0.10 should be able to open LFMs from 
trunk.


Backwards compatibility is obvious.


What I wrote is about component development and its streaming mechanism.

If you want to change forms and frames within Lazarus sources, do so 
freely. There is no need for any compatibility across different versions.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Change of lfm files

2021-01-26 Thread Ondrej Pokorny via lazarus

On 26.01.2021 09:31, Andrey Sobol via lazarus wrote:

Hello,
Let us suppose, I have changed a form inside tool/debugserver
I see what inside .lfm file a version of LCL changed  from 1.3 to 2.10 
for example.


What is policy about LCL compatibility for patches?
Where can I read about this?


We somehow internally agreed on forwards compatibility for 1 legacy version.

That means that LFM created in the latest stable Lazarus version should 
open in the stable version prior to it.


For development it means that 2.0.10 should be able to open LFMs from trunk.

Backwards compatibility is obvious.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Bump issue

2021-01-22 Thread Ondrej Pokorny via lazarus

On 22.01.2021 23:33, Michael Van Canneyt via lazarus wrote:

On Fri, 22 Jan 2021, Marco van de Voort via lazarus wrote:

Op 2021-01-22 om 22:56 schreef Michael Van Canneyt via lazarus:

I have some time this weekend, I will commit it.


Is it really a good idea to accept msec=1000 for 
TryEncodeTimeInterval in a general unit like Dateutils?


I didn't say I would commit as-is :)

I was not aware of this bugreport.
The lazarus devs should move the issue to FPC if they see it's an FPC 
issue.

(supposing they can, at least)


I cannot do that (I wanted to mode the issue yesterday). Administrator 
rights are probably needed.


Ondrej
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TimeZone problem

2021-01-18 Thread Ondrej Pokorny via lazarus

On 18.01.2021 02:30, Steve Gatenby via lazarus wrote:
Would anybody be able to point me to a solution for incorrect time 
reading ?


I obviously have a configuration problem between System and FPC - any 
pointers much appreciated :)


Lazarus 2.1.0 r64403 FPC 3.3.1 x86_64-linux-gtk2


Hello,

the linux timezone information is loaded in file 
/trunk/rtl/unix/timezone.inc


You should check the functions GetTimezoneFile and ReadTimezoneFile.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] question with IDE

2021-01-15 Thread Ondrej Pokorny via lazarus

On 15.01.2021 13:34, Mattias Gaertner via lazarus wrote:
Do you have a complete example unit (you can strip the statements and 
vars)? 


See the attachment for two example units - obviously I cannot guarantee 
it is the same scenario that duilio experiences but it is definitely an 
example of Ctrl+Shift+C generating a duplicate method.


In general: if you delete a method A and add a method B to the interface 
whereas A and B are of different types ("class constructor" vs 
"constructor" vs "procedure/function") you get a duplicate.


I have known about this bug for a long time but have been too lazy to 
fix it :(




Do you use IFDEFs?


No.

Ondrej

unit Unit1;

{$mode objfpc}

interface

type
  TMyClass = class
  public
procedure DoClick(Sender: TObject);
  end;

implementation

{ TMyClass }

constructor TMyClass.Create;
begin
  inherited Create;

  Writeln('Create');
end;

end.

unit Unit2;

{$mode objfpc}

interface

type
  TMyClass = class
  public
class constructor Create;
  end;

implementation

{ TMyClass }

constructor TMyClass.Create;
begin
  inherited Create;

  Writeln('Create');
end;

end.

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TComboBox: Is different behaviour when DroppedDown possible?

2021-01-04 Thread Ondrej Pokorny via lazarus

On 04.01.2021 15:28, frans via lazarus wrote:
I'm searching for an alternative behaviour of the TComboBox when 
scrolling through the DroppedDown list. The selected item is also 
displayed in the text field. But I would that text field unchanged 
until the selected item is accepted by Enter. I've been searching the 
internet but can't find anything.
My own programming skills are not of a level to create a solution 
myself. Did anyone else tried something like this?


TComboBox is a native control on all widgetsets, that means its behavior 
is under the control of the OS. I don't know what platform you are on, 
but at least on Windows this cannot be customized. You would need a 
completely custom TComboBox alternative.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Default project ?

2020-11-19 Thread Ondrej Pokorny via lazarus

On 19.11.2020 18:07, Michael Van Canneyt via lazarus wrote:

I'll post a feature request in the bugtracker.


Yes, that is the best you can do :)

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] error in https://www.freepascal.org/docs-html/rtl/math/floor.html

2020-11-19 Thread Ondrej Pokorny via lazarus

On 19.11.2020 13:23, Dr Engelbert Buxbaum via lazarus wrote:

the example on the bottom was apparently copied from the documentation of the 
ceil function. The results were changed for floor, but the function call was 
not.


Correct, thanks for reporting, I fixed that.

BTW, this is FPC documentation, so better to report to the fpc-devel 
mailing list.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Default project ?

2020-11-18 Thread Ondrej Pokorny via lazarus

On 18.11.2020 09:04, Bart via lazarus wrote:

On Wed, Nov 18, 2020 at 8:43 AM Michael Van Canneyt via lazarus
 wrote:


If you tell the IDE not to reload the last project when starting, it creates
a default GUI application. Since 99,99% of my programs are console programs,

And it would be nice if you could define default compiler settings for
console programs that differ from those used for GUI applications.
ATM my debug settings for GUI applications depend on the LazUtils
package, so that won't (be default) compile with console programs.


IMO better would be to have compiler settings presets (=named list). 
Then, of course, it's easy to implement to be able to pick up the 
default settings for each project type from the presets list.


Also, I am bugged by the fact that I cannot delete the (currently 
global) default compiler settings that I once set.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] AutoCommit

2020-11-14 Thread Ondrej Pokorny via lazarus

On 14.11.2020 18:02, Michael Van Canneyt via lazarus wrote:

On Sat, 14 Nov 2020, Sven Barth via lazarus wrote:

No, cause their intended default value could be True. Thus no special
handling for them.


You can of course say the same for all other types for which an 
implicit 'default'
is implemented. The more so because a class is initialized with 0 in 
which

case every enumerated and boolean will be ord(0) unless otherwise
initialized in the constructor.

So I don't see why this rule is not applied to all properties, I don't 
think

it is logical.


I agree. One would not expect the implicit default values for 
string/real/pointer properties.


And then people wonder why their empty string properties are not streamed:

TMyClass = class
published
  property MyString: string read FString write FString stored 
IsMyStringStored;

end;

constructor TMyClass.Create;
begin
  FMyString := 'abc';
end;

function TMyClass.IsMyStringStored: Boolean;
begin
  Result := FMyString<>'abc';
end;

What's wrong?
-> The nodefault is missing in order the empty string be streamed:
  property MyString: string read FString write FString stored 
IsMyStringStored nodefault;


Not logical, not intuitive, but that is how it works and is documented :/

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] AutoCommit

2020-11-14 Thread Ondrej Pokorny via lazarus

On 14.11.2020 11:26, Michael Van Canneyt wrote:

On Sat, 14 Nov 2020, Ondrej Pokorny wrote:
Then I saw the next chapter "Overriding properties". It wrongly 
described redeclaring of properties as overriding. I fixed that as 
well in r1778.


I think the difference is rather artificial, but if you think this is 
better: great.


You are right. I didn't know one can override also read/write specifiers 
(I thought one must redeclare the property in that case):


  TAncestor = class(TComponent)
  private
    fPropName: string;
  published
    property PropName: string read fPropName write fPropName;
  end;
  TOverride = class(TAncestor)
  private
    fPropName2: string;
  published
    property PropName read fPropName2 write fPropName2; // no type 
declaration

  end;

But anyway as stated in the Delphi docs 
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi)#Property_Overrides_and_Redeclarations 
:


/Whether a property is hidden or overridden in a derived class, property 
look-up is always static./


So you are right - there is no real difference in property 
override/reintroduce like there is override/overload/reintroduce 
difference in object methods.


I'll make that more clear in FPC docs.

Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] AutoCommit

2020-11-13 Thread Ondrej Pokorny via lazarus

On 13.11.2020 21:23, Juha Manninen via lazarus wrote:
On Fri, Nov 13, 2020 at 6:19 PM Larry Dalton via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


So we lose some backwards portability?


IIRC it has been called "forward compatibility" as opposed to 
"backward compatibility".
Backward compatibility means your old code works in new versions of 
FPC/LCL/Lazarus.
The other direction is not guaranteed. New code cannot always be used 
in old versions.


Exactly.

Although in case of LFM streaming we usually try to help with default 
property values as we discussed before. And yes, I usually forget to add 
the default values as well :)


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] AutoCommit

2020-11-13 Thread Ondrej Pokorny via lazarus

On 13.11.2020 22:37, Michael Van Canneyt via lazarus wrote:

On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote:
Usually we try to use the "default" feature of the newly added 
properties so that they are streamed only when really set and used. 
When they are not used, the LFM can still be loaded in a legacy 
version of Lazarus because the new properties are not streamed.


I set defaults on all boolean properties of sqlscript, rev. 47412

Strange, I thought that boolean properties were not streamed if they 
had value 'false'.
The FPC documentation is spot on about the stored/default modifiers: 
https://www.freepascal.org/docs-html/ref/refsu38.html


Only "/String, floating-point and pointer properties have 
implicitdefault//value of empty string, 0 or nil, respectively. 
Ordinal and set properties have no implicit//default//value./"


I polished the docs section in r1777 a little bit.

Then I saw the next chapter "Overriding properties". It wrongly 
described redeclaring of properties as overriding. I fixed that as well 
in r1778.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] AutoCommit

2020-11-13 Thread Ondrej Pokorny via lazarus
Usually we try to use the "default" feature of the newly added 
properties so that they are streamed only when really set and used. When 
they are not used, the LFM can still be loaded in a legacy version of 
Lazarus because the new properties are not streamed.


Ondrej


On 13.11.2020 17:47, Michael Van Canneyt via lazarus wrote:


Yes, but that's always so when properties are added to components.

Michael.

On Fri, 13 Nov 2020, Larry Dalton wrote:


So we lose some backwards portability?

Sent from my iPhone

On Nov 13, 2020, at 11:06, Michael Van Canneyt 
 wrote:



Your .lfm file contains a property "autocommit" that exists in 
2.0.10 but not in 2.0.6.
I think 2.0.10 is based on FPC 3.2.0 and 2.0.6 was still based on 
3.0.4.


A lot of new properties appeared between 3.0.4 and 3.2.0.

Michael.


On Fri, 13 Nov 2020, Larry Dalton via lazarus wrote:

I forgot to add that it compiles correctly, but then I get the 
runtime error

Sent from my iPhone

On Nov 13, 2020, at 11:02, Larry Dalton  
wrote:
This is only when I try to compile on Lazarus 2.0.6 on Windows. 
The project works fine on 2.0.10 on Linux. Any ideas?

Sent from my iPhone
On Nov 13, 2020, at 10:58, Larry Dalton  
wrote:
Error code “Project ** raised exception class ‘EReadError 
with unknown property ‘AutoCommit’

Sent from my iPhone

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus






-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]

2020-10-09 Thread Ondrej Pokorny via lazarus

On 09.10.2020 14:11, Martin Frb via lazarus wrote:

On 09/10/2020 09:06, Ondrej Pokorny via lazarus wrote:
But the ligatures are not very promising. I get ':=' as ligature but 
nothing else.


You probably will see more inside comments or strings, or if the 
highlighter is off.


In my tests, I did get in normal pascal source <= >= ..
But not ... or =>

The latter are not a single token to the highlighter, so they get 
broken into text fragments.


Ah, that's true.

Ondrej
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Win 7 issue / Re: -dWINDOWS_LIGATURE [[Re: Font ligatures support]]

2020-10-09 Thread Ondrej Pokorny via lazarus

On 09.10.2020 04:33, Martin Frb via lazarus wrote:

It might be dead simple (at least I hope)

{$IFDEF WINDOWS_LIGATURE}
function GetCharacterPlacementW(hdc: HDC; lpString: LPCWSTR; nCount, 
nMaxExtend: Integer; var lpResults: GCP_RESULTSW; dwFlags: DWORD): 
DWORD; stdcall; external 'gdi32' name 'GetCharacterPlacementW';

{$ENDIF}

Add stdcall.


Yes, the stdcall fixes the crash for me on Windows 10 64bit & Lazarus 
IDE 32bit.


But the ligatures are not very promising. I get ':=' as ligature but 
nothing else.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Feature Request: Override/Implement methods

2020-10-08 Thread Ondrej Pokorny via lazarus

On 08.10.2020 02:02, Mattias Gaertner via lazarus wrote:

As for overrides:
Insert a new line in the class declaration, Ctrl+Space, select the
parent method. This will create an override.


And the same goes for interfaces. Ctrl+Space offers methods from 
interfaces as well.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Debugging in Lazarus, cannot inspect values at breakpoints...

2020-09-30 Thread Ondrej Pokorny via lazarus

On 30.09.2020 12:34, Martin Frb via lazarus wrote:

On 30/09/2020 11:54, Ondrej Pokorny via lazarus wrote:

Tooltip evaluation: works for me
Watches: works for me
Local Variables: doesn't work for me - strange, I have to re-check. I 
thought it worked here.

Locals do not have the type info

Gdb returns them as just a pair of name value strings.

Of course the backend could run each of them a watch. That will be a 
bit slower though.


Aahhh, thanks - I remember now. I did it for locals (I obtained the type 
info for every locals entry) but it made debugging so painfully slow 
that I reverted it.


Thanks for the info - I don't have to check now again.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Debugging in Lazarus, cannot inspect values at breakpoints...

2020-09-30 Thread Ondrej Pokorny via lazarus

On 30.09.2020 11:33, Michael Van Canneyt wrote:

On Wed, 30 Sep 2020, Ondrej Pokorny via lazarus wrote:
Yes, I implemented them, IIRC. Don't remember the details, though. I 
added TDate, TDateTime and TTime formatters. It was quite a simple 
addon, should be easy to find in the sources.


Good news :-)

How to activate them ? Because everywhere I tried, a TDateTime is still
displayed as a float: 44104.47848875 does not look like a date/time I can
recognize...  :-)

I tried tooltip evaluation, evaluate/modifiy, inspect, local variables,
watches. None of them seems to use this.


Strange, they are enabled by default. They get activated in 
ide\debugmanager.pas :

constructor TDebugManager.Create(TheOwner: TComponent);
//...
  RegisterValueFormatter(skSimple, 'TDate', @DBGDateTimeFormatter);
  etc.

Tooltip evaluation: works for me
Watches: works for me
Local Variables: doesn't work for me - strange, I have to re-check. I 
thought it worked here.

Inspect: OK, I forgot about this one
Evaluate/modify: forgot about this one as well - but probably we need 
the reversed function as well to be able to write the modified formatted 
value back.


The problem of object-based visualizers like a visualizer for 
TStrings is that your Lazarus IDE has to be compiled with the same 
FPC version/codebase that you also use for the debugged program. In 
Delphi this is usually the case (if you don't fiddle with RTL sources 
to fix bugs). In FPC/Lazarus this doesn't need to apply. I usually 
build Lazarus IDE less frequently than I update and build FPC trunk. 
Or you can build Lazarus with FPC stable but develop applications 
with FPC trunk. In that case such additions are unsafe.


I understand this need to keep versions aligned, but for the average 
user who simply installs Lazarus, this will always be the case: they 
get lazarus/FPC bundled.


In this matter the Laz/FPC developers are the exception.
(one could think "it's their own fault that they make it difficult" ;-) )

So with this caveat in mind, I think support for object-based visualizers
should definitely be added. Lazarus can easily enough detect that the 
version
of FPC it uses for a project differs from the FPC version the IDE was 
compiled

with, and disable the object-based visualizers.


I probably said bullshit here. We get the detailed information about the 
object contents from the debugger, we don't use the object directly. So 
it should be possible with different FPC/RTL versions. This, of course, 
needs a much more sophisticated visualizer support in the IDE than there 
currently is. But that should be not really hard to make.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Debugging in Lazarus, cannot inspect values at breakpoints...

2020-09-30 Thread Ondrej Pokorny via lazarus

On 30.09.2020 10:55, Michael Van Canneyt via lazarus wrote:

Does Lazarus offer the functionality Delphi has (since quite some time, I
might add):  custom debug info visualizers ?

See

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers

Seems like a useful addition. Don't know if it is technically 
feasible, though.


Yes, I implemented them, IIRC. Don't remember the details, though. I 
added TDate, TDateTime and TTime formatters. It was quite a simple 
addon, should be easy to find in the sources.


The problem of object-based visualizers like a visualizer for TStrings 
is that your Lazarus IDE has to be compiled with the same FPC 
version/codebase that you also use for the debugged program. In Delphi 
this is usually the case (if you don't fiddle with RTL sources to fix 
bugs). In FPC/Lazarus this doesn't need to apply. I usually build 
Lazarus IDE less frequently than I update and build FPC trunk. Or you 
can build Lazarus with FPC stable but develop applications with FPC 
trunk. In that case such additions are unsafe.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Is there a TSpinButton component in Lazarus?

2020-09-20 Thread Ondrej Pokorny via lazarus

On 21.09.2020 00:49, Bo Berglund via lazarus wrote:

When I thought that I was close to getting through all of the problems
porting an application from Delphi (I think D7-D2007) to FPC/Lazarus I
ran across TSpinButton, which is located on a form where config items
are set up.
Since Lazarus is unable to load this form I cannot see what it does or
how it looks like.


Delphi has TUpDown and TSpinButton. If I am correct they are very 
similar (TUpDown being the WIndows native and TSpinButton being a custom 
control).



Is there any such component avilable for Lazarus?


The LCL has only the TUpDown.



According to Google there seems to be a "TSpinButton" in Delphi, but I
cannot find it in Delphi7 at least (but I have also lost TSpinEdit
from Delphi7...).
What does TSpinButton do and is there a Lazarus companion?

And is there a way in Lazarus to search for a component instead of
flipping through all of the palette tabs looking for a candidate
image?


Main Menu -> View -> Components.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Mac: High DPI TImage and TTrayIcon

2020-09-20 Thread Ondrej Pokorny via lazarus

On 20.09.2020 14:17, Tobias Giesen via lazarus wrote:

Hello,

I am finally trying to give my app some high DPI icons and graphics.

Many thanks for the High DPI demos, which help a lot!

However I have no idea if it is possible to have a high DPI TImage and
TTrayIcon? Is there maybe some runtime code needed to make it possible?


TImage: yes - just use an image with a higher resolution.

TTrayIcon: no idea about mac. I haven't worked on this one.



It would be so great if a TImage could get its picture from an image list.
Is such a feature available anywhere, maybe in a third party component?


Such a component is pretty easy to write - just a few lines of code. I 
wrote one myself.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TextHint in TComboBox

2020-08-13 Thread Ondrej Pokorny via lazarus

On 13.08.2020 21:33, Juha Manninen via lazarus wrote:

On Thu, Aug 13, 2020 at 9:54 PM Ondrej Pokorny via lazarus
 wrote:

So for TMemo we need the emulated code, which works now with a minor bug
(the TextHint is not visible when the form is shown the first time).
Strangely the bug is present only in a themed application, not in an
unthemed one.

Please test with the demo by Lagunov Aleksey in
  https://bugs.freepascal.org/view.php?id=37553
adding the line
  Memo1.TextHint:='My own TextHint';
as seen in my note.
Also remember to change function TCustomMemo.CanShowEmulatedTextHint.
It now returns False always.
The emulation does not work with GTK2.


Why have you removed the (FTextHint <> '') check in CanShowEmulatedTextHint?

Why should the emulated text hint be shown if there is none?

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TextHint in TComboBox

2020-08-13 Thread Ondrej Pokorny via lazarus

On 13.08.2020 17:58, Juha Manninen via lazarus wrote:

On Thu, Aug 13, 2020 at 6:50 PM Juha Manninen  wrote:

AFAIK it is not emulated on Windows. LCL-Win32 reports LCLCapability
flag lcTextHint.

Actually it is emulated for older Windows versions.
function TWin32WidgetSet.GetLCLCapability has :
   ...
 lcTextHint:
 begin
   if (ComCtlVersion >= ComCtlVersionIE6) then
 Result := LCL_CAPABILITY_YES
   else
 Result := LCL_CAPABILITY_NO;
 end;

For Windows 10 it should report LCL_CAPABILITY_YES.


Funnily I tested with themes off, so I got LCL_CAPABILITY_NO :)

But yes, you are correct. That is not optimal. We need to split 
lcTextHint into lcTextHintEdit and lcTextHintMemo. Because as I wrote 
before WinAPI doesn't support TextHint for multi-line text boxes 
(TMemo): 
https://docs.microsoft.com/en-us/windows/win32/api/commctrl/nf-commctrl-edit_setcuebannertext


So for TMemo we need the emulated code, which works now with a minor bug 
(the TextHint is not visible when the form is shown the first time). 
Strangely the bug is present only in a themed application, not in an 
unthemed one.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TextHint in TComboBox

2020-08-13 Thread Ondrej Pokorny via lazarus

On 13.08.2020 15:15, Juha Manninen via lazarus wrote:

On Thu, Aug 13, 2020 at 3:23 PM Ondrej Pokorny via lazarus
 wrote:

If I am not mistaken, TEdit has TextHint-emulation for WidgetSets
without native support. There is no reason why the same emulation
shouldn't work with TMemo.

It does not. Actually it never worked. Nobody has tested it maybe
because TMemo.TextHint was not published.


Emulated TMemo.TextHint (r63708) works perfectly on Win32 (Windows 10). 
I haven't checked your more recent changes. WinAPI doesn't support 
TMemo.TextHint natively.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TextHint in TComboBox

2020-08-13 Thread Ondrej Pokorny via lazarus

On 13.08.2020 14:10, Juha Manninen via lazarus wrote:

TextHint in TMemo works only with widgetset's native support. It works
with QT5 but not with GTK2.
The emulation for TMemo turned out to be tricky. It may never be
implemented, unless somebody provides a patch of course.


If I am not mistaken, TEdit has TextHint-emulation for WidgetSets 
without native support. There is no reason why the same emulation 
shouldn't work with TMemo.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] How many timers available on Linux (Raspberry Pi)?

2020-07-22 Thread Ondrej Pokorny via lazarus

On 22.07.2020 11:44, Michael Van Canneyt via lazarus wrote:
Probably the NNTP mirror is still using the old address in that case. 
Unfortunately, I don't know who maintains it...


I do not maintain it, but I requested an email address update for the 
lazarus mailing list on https://admin.gmane.io/


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Hide in "code completion" text non involved in code (not stated)

2020-05-03 Thread Ondrej Pokorny via lazarus

On 03.05.2020 20:22, Mattias Gaertner via lazarus wrote:

On Sun, 3 May 2020 18:41:54 +0200
Salvatore Coppola via lazarus  wrote:


Hi,
is there a way to avoid listing the items labeled with "text" in "code
completion"?
See the attached screenshot

Settings: IDE Options / Codetools / Identifier Completion / Include
identifiers containing prefix.

https://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes#IDE_Changes


Actually it is the option next to it :) Mentiond in the same docs.

IDE Options -> Codetools -> Identifier Completion -> Include words -> 
don't include


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TComboBox.ReadOnly

2020-05-02 Thread Ondrej Pokorny via lazarus

On 02.05.2020 16:15, Juha Manninen via lazarus wrote:
On Sat, May 2, 2020 at 11:37 AM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


Yes, sorry - you are right. I missed that. I would just remove it.


Ok, I removed it in r63112.


Great, thank you, Juha!

Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TComboBox.ReadOnly

2020-05-02 Thread Ondrej Pokorny via lazarus

On 02.05.2020 09:00, Juha Manninen via lazarus wrote:
On Sat, May 2, 2020 at 9:09 AM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


From what I can see the ReadOnly property is still published. I would
remove it completely, there is no reason to have it anymore if it was
deprecated for 3 years. Not even in the public section. (Again, even
with ReadOnly=True you can still change the value with the drop down.)


No, the published property is gone. You must rebuild the IDE before it 
disappears from OI.

There is a public TCustomComboBox.ReadOnly


Yes, sorry - you are right. I missed that. I would just remove it.



This works in Lazarus as well:

procedure TForm1.Button1Click(Sender: TObject);
begin
   // make combobox read-only (make sure ComboBox1.Style=csDropDown)
   SendMessage(GetWindow(ComboBox1.Handle, GW_CHILD), EM_SETREADONLY,
Ord(True), 0);
end;


Works only with LCL-Win32.


That's obvious :) I wanted to stress that we never had a ReadOnly 
property Jamie wanted so there was nothing to be re-enabled. Also, 
Delphi never had it so he was wrong about "I understand latest Delphi 
eliminated it [ReadOnly property]".


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] TComboBox.ReadOnly

2020-05-01 Thread Ondrej Pokorny via lazarus

On 01.05.2020 23:36, Juha Manninen via lazarus wrote:
I applied my own patch. It removes the deprecated published property 
so it will be gone in Lazarus 2.2. A public ReadOnly property remains 
but is cannot be assigned any more. Thus ReadOnly property is itself 
readonly. :)

Please test.


From what I can see the ReadOnly property is still published. I would 
remove it completely, there is no reason to have it anymore if it was 
deprecated for 3 years. Not even in the public section. (Again, even 
with ReadOnly=True you can still change the value with the drop down.)


As for Jamie's issue. I took a look at the state before I deprecated it 
and it was a way to disable editing for csOwnerDrawFixed, 
csOwnerDrawVariable styles - so actually a duplicate property for the 
Style property. It had no other function.


It was not an equivalent for a "readonly edit" (=you can select text but 
cannot change it by typing) and enabled drop-down list. Something that 
can be achieved with EM_SETREADONLY as described in 
http://mc-computing.com/Languages/Delphi/ReadOnly.html


This works in Lazarus as well:
procedure TForm1.Button1Click(Sender: TObject);
begin
  // make combobox read-only (make sure ComboBox1.Style=csDropDown)
  SendMessage(GetWindow(ComboBox1.Handle, GW_CHILD), EM_SETREADONLY, 
Ord(True), 0);

end;

So, IMO the removal of the ReadOnly property is valid because it was not 
implemented with EM_SETREADONLY as Jamie expected and was only confusing 
the way it was implemented.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Enhancements to ToDoList

2020-03-31 Thread Ondrej Pokorny via lazarus

On 31.03.2020 14:33, Kevin Jesshope via lazarus wrote:
Is it best submitted via the bug tracker as one large patch or a 
separate patch per file in a compressed archive?


Best is several patches separated by features and refactorings.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Close all menu item ?

2020-03-24 Thread Ondrej Pokorny via lazarus

On 24.03.2020 9:08, Michael Van Canneyt wrote:
So as far as I am concerned, the case for actually closing everything 
still stands.


I though "Close Project" does the thing, or isn't this good enough?

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Close all menu item ?

2020-03-23 Thread Ondrej Pokorny via lazarus

On 23.03.2020 20:26, Michael Van Canneyt via lazarus wrote:

Well, I think it does need to be closed from time to time.

Namely: I want to be sure that all is closed before doing an svn
update or git pull. Although many bugs have been fixed, still from 
time to

time when you do an update of files on disk, Lazarus messes up and
overwrites incoming changes.


I fixed a bug that rewrote the incoming LPI changes recently and that 
annoyed me for years: https://bugs.freepascal.org/view.php?id=36813


I am not aware of other bugs that would rewrite external changes. Please 
report them.


(Well, maybe there is still one bug left in the Lazarus file cache. 
Sometimes it reports wrong file datetimes. Let's see if I come across it 
at some point. I don't remember the last time I was hit by it.)


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Close all menu item ?

2020-03-23 Thread Ondrej Pokorny via lazarus

On 23.03.2020 10:59, Michael Van Canneyt via lazarus wrote:

On Mon, 23 Mar 2020, Ondrej Pokorny via lazarus wrote:

On 23.03.2020 10:23, Michael Van Canneyt via lazarus wrote:
"Close all" in the file menu does not close the project inspector 
(and, I

suppose, the project)

Is this by design ? I'm asking because in Delphi 'Close all' really 
closes "all".


Hello,

yes this difference is by design. To close the project in Lazarus IDE 
you have to execute Project -> "Close Project" from the menu. File -> 
"Close all" closes all open editors.


OK, thank you.

Any particular reason for this behaviour ? It seems a bit strange to 
me to treat the project differently.


This feature is not from me. I was hit by it as well when I started 
using Lazarus. AFAIR it's been always so. I got used to it and I find it 
logical.


I set up Lazarus to remember open editors (to reopen them when a project 
is opened) and so after some time the count of open editors grows a lot. 
This is a way to close all editors easily and have a clean source 
editor. On the contrary, If I want to close the project and keep the 
open editors remembered, I use the "Close Project" menu item.


So for me Delphi should fix their behavior to match Lazarus :)

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Close all menu item ?

2020-03-23 Thread Ondrej Pokorny via lazarus

On 23.03.2020 10:23, Michael Van Canneyt via lazarus wrote:

"Close all" in the file menu does not close the project inspector (and, I
suppose, the project)

Is this by design ? I'm asking because in Delphi 'Close all' really 
closes "all".


Hello,

yes this difference is by design. To close the project in Lazarus IDE 
you have to execute Project -> "Close Project" from the menu. File -> 
"Close all" closes all open editors.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] ApplicationProperties

2020-03-21 Thread Ondrej Pokorny via lazarus

On 21.03.2020 14:11, Michael Van Canneyt via lazarus wrote:

The TApplicationProperties component provides access to the TApplication
events and properties.

It is missing OnActionExecute. Can this be added or is there a reason for
not adding it ?


Surely it can be added.



Should I file an issue in the issue tracker ?


Yes, please.


Ondrej


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] IDE trunk cannot build on fpc 3.0.2

2020-03-20 Thread Ondrej Pokorny via lazarus

On 20.03.2020 12:05, Juha Manninen via lazarus wrote:
On Thu, Mar 19, 2020 at 10:11 AM Ondrej Pokorny via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


It is really frustrating when this happens every 10 minutes :/ I
really don't see a point to change working code to generics.

Please don't blame my refactoring if it happens every 10 minutes. It 
was a one-time shot.


I meant the internal error happens that often. Today it was good but 2 
weeks ago it was really almost impossible to work on the IDE. I changed 
3 lines of code, wanted to compile and bang, internal error :/ And that 
all the time. It must depend on the files one works on.


I have to admit that I have no evidence the internal errors are 
connected to generics. I will investigate further.


Anyway, thanks for the description and sorry for the rant.

Ondrej
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] IDE trunk cannot build on fpc 3.0.2

2020-03-19 Thread Ondrej Pokorny via lazarus

On 27.02.2020 10:03, Juha Manninen via lazarus wrote:
On Thu, Feb 27, 2020 at 7:59 AM Michael Thompson via lazarus 
mailto:lazarus@lists.lazarus-ide.org>> 
wrote:


>> On Tue, Feb 25, 2020 at 8:05 PM AlexeyT wrote
>> pkgmanager.pas(77,78) Error (5000) Id not found TObjectArray$2

I'm hitting this error on Windows.  fpc 3.0.4


I built Lazarus with with FPC 3.0.4. It works with 100% certainty.

No idea.  Warning - the following does not contain known facts! 
Wildly guessing (honestly) that for 3.0.4 the code in fgl only
accepts types and you compiled with 3.1 which may have improved
support for classes? Dunno.


A class is also a type. Generics have worked with classes from the 
beginning.


Well, generics may cause an internal error on a simple compile. A clean 
rebuild is needed to compile even after a small change.


This happens a lot for me now. Sometimes in the changes from r62639, 
sometimes in different code. If I work on the source of the Lazarus IDE 
and I recompile it, I get an internal error. Then I have to rebuild 
Lazarus IDE clean, which takes a lot of time.


It is really frustrating when this happens every 10 minutes :/ I really 
don't see a point to change working code to generics.


Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] MDI support for win32

2020-02-28 Thread Ondrej Pokorny via lazarus

Hello,

I added MDI support for win32 based on patch by Kostas Michalopoulos: 
https://bugs.freepascal.org/view.php?id=36582


Please report any regressions or problems.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Multiple type helpers not support by CodeTools

2020-02-28 Thread Ondrej Pokorny via lazarus

On 28.02.2020 17:59, Anthony Walter via lazarus wrote:
I was creating a library with uses the new {$modeswitch multihelpers} 
with multiple type helpers and it would seems CodeTools has not been 
updated to support this switch or the functionality of multiple type 
helpers per type. When you use the switch and multiple helpers 
CodeTools sees lines which use this feature as being invalid and does 
not provide any help for those lines.


I've filed a bug in Mantis:

https://bugs.freepascal.org/view.php?id=36742


Thanks, I resolved it as duplicate :)

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Patch for Screen.BeginWaitCursor

2020-02-23 Thread Ondrej Pokorny via lazarus

Where is the patch? Maybe you forgot to attach it?

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] ProjectGroups: fixed LPG XML structure

2019-11-15 Thread Ondrej Pokorny via lazarus

On 15.11.2019 21:53, Mattias Gaertner via lazarus wrote:

On Fri, 15 Nov 2019 21:29:10 +0100
Ondrej Pokorny via lazarus  wrote:


Hello,

I just fixed the XML structure of LPG project group files.

What was the bug?


1.) The  elements were not placed within the  element.

2.) I updated the structure like I did for the LPI files: 
https://bugs.freepascal.org/view.php?id=22752



Old files
will be loaded correctly but the new LPG file cannot be opened in a
legacy Lazarus installation.

AFAIK project groups are usable only in trunk so this does not matter
(?) Otherwise we would need some legacy option checkbox like it is in
the LPI project files.

Don't forget to add it to
https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes


Thanks for the reminder. I'll update the page about both LPG and LPI files.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] ProjectGroups: fixed LPG XML structure

2019-11-15 Thread Ondrej Pokorny via lazarus

Hello,

I just fixed the XML structure of LPG project group files. Old files 
will be loaded correctly but the new LPG file cannot be opened in a 
legacy Lazarus installation.


AFAIK project groups are usable only in trunk so this does not matter 
(?) Otherwise we would need some legacy option checkbox like it is in 
the LPI project files.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Annoying code completion failure

2019-11-03 Thread Ondrej Pokorny via lazarus

On 03.11.2019 23:31, Sven Barth via lazarus wrote:
Maybe Michael should file a bug report then... (and I should collect 
my annoyances as well :P)


Yes, that is definitely a good idea. I face myself 1-2 annoyances as 
well that I haven't fixed yet.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Annoying code completion failure

2019-11-03 Thread Ondrej Pokorny via lazarus


On 03.11.2019 17:49, Sven Barth via lazarus wrote:
Ondrej Pokorny via lazarus <mailto:lazarus@lists.lazarus-ide.org>> schrieb am So., 3. Nov. 2019, 
11:21:


On 02.11.2019 11:23, Michael Van Canneyt via lazarus wrote:
> TStrings has a property
>
>     property Values[const Name: string]: string read GetValue write
> SetValue;
>
> The setter is defined as:
>
> procedure SetValue(const Name, Value: string);
>
> Note that both arguments are 'const'
>
> When adding a new property, and pressing 'CTRL-C', the IDE adds
the new
> property, but also insists on adding a new SetValue:
>
> procedure SetValue(const Name: string; AValue: string);
>
> Note the missing const on the second parameter.
>
> It does this of course not only for TStrings, but for all such
properties.

The problem is not the const - Lazarus can ignore it. The problem is
that the parameters are joined - that is what Lazarus cannot handle.

Replace
 procedure SetValue(const Name, Value: string);
with
 procedure SetValue(const Name: string; const Value: string);

then Lazarus won't add it every time you do class completion. I
know -
it's not what you currently have in the interface, but the
difference is
just cosmetic. I usually let Lazarus do its job and don't care
that the
parameters are separated.


This is not what one wants to hear.


Well, I just explained the current state. It doesn't mean it cannot be 
improved.



Lazarus really likes to mess with existing code and it's one of the 
main reasons I'm *not* using class completion inside the compiler, 
cause otherwise I can be sure that the whole remaining class is 
changed as well -.-


To be honest, the compiler code style is very quirky :)

Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Annoying code completion failure

2019-11-03 Thread Ondrej Pokorny via lazarus

On 02.11.2019 11:23, Michael Van Canneyt via lazarus wrote:

TStrings has a property

    property Values[const Name: string]: string read GetValue write 
SetValue;


The setter is defined as:

procedure SetValue(const Name, Value: string);

Note that both arguments are 'const'

When adding a new property, and pressing 'CTRL-C', the IDE adds the new
property, but also insists on adding a new SetValue:

procedure SetValue(const Name: string; AValue: string);

Note the missing const on the second parameter.

It does this of course not only for TStrings, but for all such properties.


The problem is not the const - Lazarus can ignore it. The problem is 
that the parameters are joined - that is what Lazarus cannot handle.


Replace
    procedure SetValue(const Name, Value: string);
with
    procedure SetValue(const Name: string; const Value: string);

then Lazarus won't add it every time you do class completion. I know - 
it's not what you currently have in the interface, but the difference is 
just cosmetic. I usually let Lazarus do its job and don't care that the 
parameters are separated.


Furthermore, you can make Lazarus to add the "const" automatically in 
IDE options -> Codetools -> Class Completion -> Property completion -> 
use const. You can also define an own parameter name or prefix (I use a 
prefix).


Ondrej
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Lazarus 2.0.6 IDE suddenly disappeared losing a lot of edits...

2019-11-01 Thread Ondrej Pokorny via lazarus

On 01.11.2019 23:03, Martin Frb via lazarus wrote:

Well and a "autosave" feature might be nice, but needs to be written...


The project is always automatically saved when you compile it.

Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] LazDataDesktop: transaction handling

2019-09-04 Thread Ondrej Pokorny via lazarus

On 05.09.2019 8:20, Michael Van Canneyt via lazarus wrote:

The grid was never meant to be editable. I simply forgot to disable that.
(I myself never ever edit in a grid, it didn't appear in my head that
someone would do this)

But I will :
a) Add the sqoAutoApplyUpdates option.
b) Add buttons for more explicit transaction control.


Thank you Michael. I assume I can help you with that.

I can also help with the editable grid. Editing could be enabled only if 
the table has a primary key or a unique index, for example. I sometimes 
need to edit raw data when something went wrong during the 
development/debugging. (And I tend to be lazy to type an UPDATE 
statement manually although LazDataDesktop offers a template for it :) )


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] LazDataDesktop: transaction handling

2019-09-04 Thread Ondrej Pokorny via lazarus

Hello (Michael)!

I started to use LazDataDesktop because PgAdmin4 is horrible.

I have a problem with transactions with Postgres connection (well I 
tested only Postgres connection).


I found out that when using the SQL editor, I can type "COMMIT" and 
"ROLLBACK" - so far so good. (Well I would like to have a tool button 
for these commands but OK for now - I may add them in the future.)


The real problem: I cannot apply edited data from the DB grid. I keep 
getting this error:


I have clicked on the tick button - it got disabled. I have also clicked 
on the button next to refresh - well I don't know that the button does 
because it has no hint and caption, but I clicked on it nevertheless :) :


But still I get the error above and the data is not written.

How can I commit the changes made in the data grid?

Thanks
Ondrej

-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Project Groups are saving LPI files

2019-08-31 Thread Ondrej Pokorny via lazarus

On 28.08.2019 09:23, Ondrej Pokorny via lazarus wrote:

On 17.08.2019 16:53, Mattias Gaertner via lazarus wrote:

On Thu, 15 Aug 2019 13:43:58 +0200
Ondrej Pokorny via lazarus  wrote:


[...]
Project groups are saving my LPI files upon loading the project
group.

Huh? Do you really mean, merely opening a lpg touches some lpi files?


Yes, this is exactly what happens. The project group rewrites all lpi 
files within the project group itself.


I reported it: https://bugs.freepascal.org/view.php?id=36030

Ondrej
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] Project Groups are saving LPI files

2019-08-28 Thread Ondrej Pokorny via lazarus

On 17.08.2019 16:53, Mattias Gaertner via lazarus wrote:

On Thu, 15 Aug 2019 13:43:58 +0200
Ondrej Pokorny via lazarus  wrote:


[...]
Project groups are saving my LPI files upon loading the project
group.

Huh? Do you really mean, merely opening a lpg touches some lpi files?


Yes, this is exactly what happens. The project group rewrites all lpi 
files within the project group itself.




TXMLConfig.CreateClean;
TXMLConfig.Flush; -> should write, so needs Modified=true

Maybe it is a bad idea to auto flush on Destroy.


So what is the reason to have the modified flag when it is set to true 
on loading - when the file is definitely not modified?


Another idea would be to have a "Force: Boolean" parameter in Flush that 
would ignore the modified flag and write anyway.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] Project Groups are saving LPI files

2019-08-15 Thread Ondrej Pokorny via lazarus

Hello (Mattias)!

Project groups are saving my LPI files upon loading the project group. 
This is a problem because they resave LPIs without BOM and then all LPIs 
are marked as modified in SVN because they were saved with BOM. (Lazarus 
IDE saves my project files with BOM.)


I searched the reason and found out that TXMLConfig is the problem. 
There are 2 issues:


1.) TXMLConfig should keep the original encoding along with BOM.
2.) Project groups should never save LPIs.

About 2.:
The problem is:
constructor TXMLConfig.CreateClean(const AFilename: String);
begin
  //DebugLn(['TXMLConfig.CreateClean ',AFilename]);
  fDoNotLoadFromFile:=true;
  Create(AFilename);
  FModified:=FileExistsCached(AFilename);
end;

FModified gets True here - why? Is there a reason why the config should 
be set as Modified on create and consequently be resaved on Free when 
FileExistsCached returns true?


Setting the Modified flag to False in TIDECompileTarget.LoadProject 
before xml.Free is definitely a fix but IMO it should be fixed within 
TXMLConfig.


---
The above code could be a cause for another problem as well - when the 
currently open LPI project file is modified externally (e.g. SVN 
update), Lazarus IDE asks to reload the project but sometimes the LPI 
file is rewritten by the IDE and the new external changes get lost. I 
experienced this issue before installing Project groups but could not 
find clear steps-to-reproduce and could not find the reason for it.


Ondrej

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


  1   2   3   4   5   >