Re: [Lazarus] MJPEG streamer
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
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
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
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
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
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
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
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
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
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
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 (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
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
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
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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.
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.
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.
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
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 ?
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 ?
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 ?
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 ?
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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 ?
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
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 ?
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
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
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
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
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
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]]
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]]
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
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...
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...
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...
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?
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
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
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
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
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
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)?
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)
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
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
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
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
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 ?
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 ?
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 ?
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 ?
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
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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
Re: [Lazarus] It is a beautiful day...
On 11.08.2019 13:12, Mattias Gaertner via lazarus wrote: On Sun, 11 Aug 2019 12:54:48 +0200 Ondrej Pokorny via lazarus wrote: The issue is that the new format is done with forwards-compatibility so that people can decide if they want to open the new file in an older Lazarus version. (The projects have the "Maximize compatibility of project files" option for this.) That an old Lazarus cannot read completely the new format is an incompatibility I can live with, if it is documented. Thanks, I'll come up with a patch. Best Ondrej -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] It is a beautiful day...
On 11.08.2019 12:23, Mattias Gaertner via lazarus wrote: I suggest to fix the old file format without backwards-compatibility: That would mean that the Compile flags for build modes get lost and the user must set them again. Are you fine with it? (Well, I am fine with that.) I guess with a few lines of code you can read the old format and set the "Compile" flag. The issue is that the new format is done with forwards-compatibility so that people can decide if they want to open the new file in an older Lazarus version. (The projects have the "Maximize compatibility of project files" option for this.) Is this important to you? Ondrej -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
