Re: [Lazarus] Special Request: Theme entire IDE support

[Anthony Walter via Lazarus]

Ralf, I believe your response was to to dark screenshot. I was hoping
people would not consider one particular style and judge customization one
that, but rather the idea of making customization of colors and size user
accessible.

Regarding completeness of custom colors and themes, yes some items may not
be easily themed, such as scrollbars. IMO though an attempt would not have
to 100% complete at that start. That is, creating an simplified way to
change some or most of the colors and size would be a good start.
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Special Request: Theme entire IDE support

[Ralf Quint via Lazarus]

On 3/9/2018 7:41 PM, Anthony Walter via Lazarus wrote:
I just wanted to put this idea out there, which I feel would bring 
significant pleasure to a lot of Lazarus users.


Would someone consider adding or working on support to theme the 
entire Lazarus IDE? I've found myself quite fond of darker themed IDE, 
such as VS code:


Darker themed IDE example 




Oh, hell no!...

(sorry, but you asked)

Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Special Request: Theme entire IDE support

[AlexeyT via Lazarus]

 >theme the entire Lazarus IDE?

Big problem with scrollbars: Treeviews, Listboxes, Listviews, Synedits. 
I made big work to theme scrollbars in CudaText.


--
Regards,
Alexey

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

[Lazarus] Special Request: Theme entire IDE support

[Anthony Walter via Lazarus]

I just wanted to put this idea out there, which I feel would bring
significant pleasure to a lot of Lazarus users.

Would someone consider adding or working on support to theme the entire
Lazarus IDE? I've found myself quite fond of darker themed IDE, such as VS
code:

Darker themed IDE example


As it stand Lazarus has already the ability to change the color of the
source code editor, and some support for changing the object inspector
colors, and message window colors, but all three of these customization
systems operate independently of each other. Also there are many other tool
windows whose colors or styles cannot be customized, such as the components
list in the object inspector, the project manager, and elsewhere.

An optimal solution would be to add a single IDE theme dialog allowing
users controls the colors and default sizes of everything in the IDE. Items
could be categorized in simple groups such as background color, text
color/size, highlight color, border color/size, and so on. Color and size
settings could be saved using a name, restored, and exported for others to
use.

I can think of a few ways this could be implemented, mainly through
offering a hook into the Graphics unit to redefine custom values for system
colors, and a flag to denote values have been overridden.

If anyone has desire to communicate the pros/cons of this proposal (both of
the concept and implementation) could you please it discuss here?
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Object inspector bug - exception

[Juha Manninen via Lazarus]

On Thu, Mar 8, 2018 at 10:05 PM, Rik van Kekem via Lazarus
 wrote:
> But I was under the impression that using TAB in the Component-filter in
> Object Inspector would set the focus on the TreeView with the components. It
> doesn't. I never use it but apparently it sets the focus directly on the
> Property view.

The key handling in OI is a little complicated. Now the TAB is also
handled in TObjectInspectorDlg.KeyDown().
I added commens etc. in r57490. Please debug and experiment with the
code. Maybe you can fix it.

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

Re: [Lazarus] How to catch an unhandled exception? [FIXED - but there is an FPC bug here]

[Gabor Boros via Lazarus]

2018. 03. 09. 12:09 keltezéssel, Tony Whyman via Lazarus írta:
Finally, knowing all this, I go back to Gabor's program and add the line 
(again shown in context):


    repeat
   SQR:=SM.Query(nil,SRB);
   for i:=0 to SQR.GetCount-1 do
    begin
  case SQR[i].getItemType of isc_info_svc_line:begin
s:=SQR[i].getAsString;
   end;
  end;
  if (s<>'') then WriteLn(s);
  s := ''; {Line 
added here}

    end;
     until (s='');

and guess what - bug goes away.



Confirmed. Executed the Debug and Release builds more than 100 times 
without any exception.


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

Re: [Lazarus] How to catch an unhandled exception? [FIXED - but there is an FPC bug here]

[Tony Whyman via Lazarus]

A supplementary for anyone confused by the last extra parameter to 
SetString in the previous post (repeated below). When I wrote up the bug 
report, I should have gone one step lower in the code. The SetString 
commented out below is actually an internal function:


procedure TOutputBlockItem.SetString(out S: AnsiString; Buf: PByte;
  Len: integer; CodePage: TSystemCodePage);
var rs: RawByteString;
begin
  system.SetString(rs,PAnsiChar(Buf),len);
  SetCodePage(rs,CodePage,false);
  S := rs;
end;

However, the same result (e.g. the bug disappears) is achieved by 
commenting out the call to system.Setstring.



On 09/03/18 11:09, Tony Whyman via Lazarus wrote:


Thanks to Giuliano mentioning debug libraries I have been able to 
duplicate the problem and to find the source of the bug - but it is as 
weird as it gets.


FYI: tests done on Linux Mint 18 with Lazarus 1.8.0 and fpc 3.0.4.

The evidence so far:

1. Gabor's program ends with an exception when using the FPC release  
RTL and FCL, but not when using RTL and FCL libraries compiled for 
debugging.


2. If I use GDB to step through the final steps of the program, the 
bug disappears!


3. If I add a delay at the end (e.g. a call to sleep(1)), the bug 
disappears.


4. Playing around with code optimisations and debugging flags seems to 
have no effect.


5. Using the age old technique of commenting out bits of the code 
until the bug disappears, I tracked the problem down.


In Gabor's program, the bug is removed by commenting out this line 
(shown in context)


  for i:=0 to SQR.GetCount-1 do
   begin
 case SQR[i].getItemType of isc_info_svc_line:begin
// s:=SQR[i].getAsString;  {This is where the problem starts}
  end;
 end;
 if (s<>'') then WriteLn(s);
   end;

Going deeper into the fbintf package, I have further tracked the 
problem down to this line of code


SetString(Result,FBufPtr+3,len,CP_ACP);

FBufPtr is a pointer and it is fairly simple bit of code, copying a 
string from a buffer (received from Firebird) into an AnsiString. 
Commenting out the line stops the bug. The bug also goes away by 
changing it to


var s: string;
  i: integer;

...
 Result := '';
  SetString(s,FBufPtr+3,len,CP_ACP);
  for i := 1 to length(s) do
    Result += s[i];

which can only be described as a WTF moment. The problem has to be due 
to string disposal.


Finally, knowing all this, I go back to Gabor's program and add the 
line (again shown in context):


   repeat
  SQR:=SM.Query(nil,SRB);
  for i:=0 to SQR.GetCount-1 do
   begin
 case SQR[i].getItemType of isc_info_svc_line:begin
s:=SQR[i].getAsString;
  end;
 end;
 if (s<>'') then WriteLn(s);
 s := ''; {Line added here}
   end;
    until (s='');

and guess what - bug goes away.

It looks like what is happening is that SetString is setting an 
AnsiString in such as away as to cause a problem when the memory 
manager cleans up - but only as a race condition and if the string is 
not cleaned up explicitly.


Looks like an FPC bug report to me.

On 09/03/18 09:14, Gabor Boros via Lazarus wrote:

Hi All,

The result of the attached example (which use MWA's Firebird Pascal 
API) for me is an exception:



Gstat execution time Fri Mar  9 09:29:18 2018

Database header page information:
    Flags   0
    Generation  173
    System Change Number    0
    Page size   8192
    ODS version 12.0
    Oldest transaction  161
    Oldest active   162
    Oldest snapshot 162
    Next transaction    164
    Sequence number 0
    Next attachment ID  27
    Implementation  HW=AMD/Intel/x64 little-endian 
OS=Linux CC=gcc

    Shadow count    0
    Page buffers    0
    Next header page    0
    Database dialect    3
    Creation date   Feb 2, 2018 14:07:24
    Attributes  force write

    Variable header data:
    *END*
Gstat completion time Fri Mar  9 09:29:18 2018

Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
An unhandled exception occurred at $7FF97F0A3147:
EAccessViolation:
  $7FF97F0A3147


If comment out cthreads from the uses the exception is:


An unhandled exception occurred at $7F21B71F5147:
EAccessViolation:
  $7F21B71F5147
  $7F21B71F751B
  $7F21B71F769C
  $7F21B746BFFF


If run with gdb (and cthreads):


Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
[Thread 0x75991700 (LWP 2874) exited]
[Thread 

Re: [Lazarus] How to catch an unhandled exception? [FIXED - but there is an FPC bug here]

[Tony Whyman via Lazarus]

Thanks to Giuliano mentioning debug libraries I have been able to 
duplicate the problem and to find the source of the bug - but it is as 
weird as it gets.


FYI: tests done on Linux Mint 18 with Lazarus 1.8.0 and fpc 3.0.4.

The evidence so far:

1. Gabor's program ends with an exception when using the FPC release  
RTL and FCL, but not when using RTL and FCL libraries compiled for 
debugging.


2. If I use GDB to step through the final steps of the program, the bug 
disappears!


3. If I add a delay at the end (e.g. a call to sleep(1)), the bug 
disappears.


4. Playing around with code optimisations and debugging flags seems to 
have no effect.


5. Using the age old technique of commenting out bits of the code until 
the bug disappears, I tracked the problem down.


In Gabor's program, the bug is removed by commenting out this line 
(shown in context)


  for i:=0 to SQR.GetCount-1 do
   begin
 case SQR[i].getItemType of isc_info_svc_line:begin
// s:=SQR[i].getAsString;  {This is where the problem starts}
  end;
 end;
 if (s<>'') then WriteLn(s);
   end;

Going deeper into the fbintf package, I have further tracked the problem 
down to this line of code


SetString(Result,FBufPtr+3,len,CP_ACP);

FBufPtr is a pointer and it is fairly simple bit of code, copying a 
string from a buffer (received from Firebird) into an AnsiString. 
Commenting out the line stops the bug. The bug also goes away by 
changing it to


var s: string;
  i: integer;

...
 Result := '';
  SetString(s,FBufPtr+3,len,CP_ACP);
  for i := 1 to length(s) do
    Result += s[i];

which can only be described as a WTF moment. The problem has to be due 
to string disposal.


Finally, knowing all this, I go back to Gabor's program and add the line 
(again shown in context):


   repeat
  SQR:=SM.Query(nil,SRB);
  for i:=0 to SQR.GetCount-1 do
   begin
 case SQR[i].getItemType of isc_info_svc_line:begin
s:=SQR[i].getAsString;
  end;
 end;
 if (s<>'') then WriteLn(s);
 s := ''; {Line 
added here}

   end;
    until (s='');

and guess what - bug goes away.

It looks like what is happening is that SetString is setting an 
AnsiString in such as away as to cause a problem when the memory manager 
cleans up - but only as a race condition and if the string is not 
cleaned up explicitly.


Looks like an FPC bug report to me.

On 09/03/18 09:14, Gabor Boros via Lazarus wrote:

Hi All,

The result of the attached example (which use MWA's Firebird Pascal 
API) for me is an exception:



Gstat execution time Fri Mar  9 09:29:18 2018

Database header page information:
    Flags   0
    Generation  173
    System Change Number    0
    Page size   8192
    ODS version 12.0
    Oldest transaction  161
    Oldest active   162
    Oldest snapshot 162
    Next transaction    164
    Sequence number 0
    Next attachment ID  27
    Implementation  HW=AMD/Intel/x64 little-endian 
OS=Linux CC=gcc

    Shadow count    0
    Page buffers    0
    Next header page    0
    Database dialect    3
    Creation date   Feb 2, 2018 14:07:24
    Attributes  force write

    Variable header data:
    *END*
Gstat completion time Fri Mar  9 09:29:18 2018

Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
An unhandled exception occurred at $7FF97F0A3147:
EAccessViolation:
  $7FF97F0A3147


If comment out cthreads from the uses the exception is:


An unhandled exception occurred at $7F21B71F5147:
EAccessViolation:
  $7F21B71F5147
  $7F21B71F751B
  $7F21B71F769C
  $7F21B746BFFF


If run with gdb (and cthreads):


Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
[Thread 0x75991700 (LWP 2874) exited]
[Thread 0x76192700 (LWP 2873) exited]
[Thread 0x77fe3740 (LWP 2869) exited]
Cannot find user-level thread for LWP 2875: generic error


Any idea how to detect what/where is the source of the exception?

I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.

Gabor




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

Re: [Lazarus] How to catch an unhandled exception?

[Tony Whyman via Lazarus]

Giulian,

You may in a roundabout way have pointed me at where the problem lies. I 
always work with fpc debug libraries as well and I can't catch the 
problem. I changed to the standard release and the bug appears! 
Unfortunately, while duplicating the problem is one thing, tracking it 
down when your main debugging tool is unavailable is another...


Tony Whyman

MWA


On 09/03/18 09:56, Giuliano Colla via Lazarus wrote:

Il 09/03/2018 10:14, Gabor Boros via Lazarus ha scritto:


Any idea how to detect what/where is the source of the exception?

I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8. 


To obtain meaningful information from gdb I do the following:
1) Compile both Lazarus LCL and fpc with debug info
2) Install the glibc-debuginfo packages
Otherwise you get only the information about exceptions which generate 
directly from your source code, which is many cases isn't sufficient.


Hope that it helps,

Giuliano


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

Re: [Lazarus] How to catch an unhandled exception?

[Giuliano Colla via Lazarus]

Il 09/03/2018 10:14, Gabor Boros via Lazarus ha scritto:


Any idea how to detect what/where is the source of the exception?

I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8. 


To obtain meaningful information from gdb I do the following:
1) Compile both Lazarus LCL and fpc with debug info
2) Install the glibc-debuginfo packages
Otherwise you get only the information about exceptions which generate 
directly from your source code, which is many cases isn't sufficient.


Hope that it helps,

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

Re: [Lazarus] How to catch an unhandled exception?

[Tony Whyman via Lazarus]

Gabor,

I can't duplicate your problem which probably implies that we are 
looking at some weird race condition during the program tidy up phase. I 
did see occasionally something like this before with Lazarus 1.6.4 on 
Windows with heaptrc - but I never saw it without heaptrc and it cleared 
up with Lazarus 1.8 and hence  I never bothered to pursue it assuming 
that it was a Lazarus bug that got fixed.


You are seeing this problem not so much with IBX, but with the Firebird 
Pascal API. Your example program has excluded the IBX part and focused 
purely on the API.


What might be an issue here is that the FirebirdAPI is accessed via a 
COM interface and the IFirebirdAPI interface is not explicitly released. 
The software just relies upon the system to clean it up at the end. 
There may be a race condition here between the clear up of the interface 
and the dynamic library manager. This is because when the interface is 
released, it then unloads the Firebird DLL/SO. Try adding a finalization 
clause to IB.pas setting "FFirebirdAPI := nil" and see if that clears it 
up - or whether the exception occurs before this point.


It is not obvious if there is a real issue with cthreads. The library 
should only create multiple threads when handling asynchronous Firebird 
events and your program is not using this capability.


Otherwise, yes, it would be really useful to be able to find where this 
exception is being raised.


Tony Whyman

MWA


On 09/03/18 09:14, Gabor Boros via Lazarus wrote:

Hi All,

The result of the attached example (which use MWA's Firebird Pascal 
API) for me is an exception:



Gstat execution time Fri Mar  9 09:29:18 2018

Database header page information:
    Flags   0
    Generation  173
    System Change Number    0
    Page size   8192
    ODS version 12.0
    Oldest transaction  161
    Oldest active   162
    Oldest snapshot 162
    Next transaction    164
    Sequence number 0
    Next attachment ID  27
    Implementation  HW=AMD/Intel/x64 little-endian 
OS=Linux CC=gcc

    Shadow count    0
    Page buffers    0
    Next header page    0
    Database dialect    3
    Creation date   Feb 2, 2018 14:07:24
    Attributes  force write

    Variable header data:
    *END*
Gstat completion time Fri Mar  9 09:29:18 2018

Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
An unhandled exception occurred at $7FF97F0A3147:
EAccessViolation:
  $7FF97F0A3147


If comment out cthreads from the uses the exception is:


An unhandled exception occurred at $7F21B71F5147:
EAccessViolation:
  $7F21B71F5147
  $7F21B71F751B
  $7F21B71F769C
  $7F21B746BFFF


If run with gdb (and cthreads):


Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
[Thread 0x75991700 (LWP 2874) exited]
[Thread 0x76192700 (LWP 2873) exited]
[Thread 0x77fe3740 (LWP 2869) exited]
Cannot find user-level thread for LWP 2875: generic error


Any idea how to detect what/where is the source of the exception?

I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.

Gabor




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

[Lazarus] LCLMessageGlue.pas, typo in debug output?

[Lubos Pintes via Lazarus]

Hello,
Just noticed in LCLMessageGlue.pas on line 98:
and (TLMessage(AMessage).Msg < CN_KEYDOWN )
maybe there could be <> like on other lines in that IFDEF?
Not sure, just noticed little asymmetry.

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

[Lazarus] How to catch an unhandled exception?

[Gabor Boros via Lazarus]

Hi All,

The result of the attached example (which use MWA's Firebird Pascal API) 
for me is an exception:



Gstat execution time Fri Mar  9 09:29:18 2018

Database header page information:
Flags   0
Generation  173
System Change Number0
Page size   8192
ODS version 12.0
Oldest transaction  161
Oldest active   162
Oldest snapshot 162
Next transaction164
Sequence number 0
Next attachment ID  27
Implementation  HW=AMD/Intel/x64 little-endian OS=Linux 
CC=gcc

Shadow count0
Page buffers0
Next header page0
Database dialect3
Creation date   Feb 2, 2018 14:07:24
Attributes  force write

Variable header data:
*END*
Gstat completion time Fri Mar  9 09:29:18 2018

Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
An unhandled exception occurred at $7FF97F0A3147:
EAccessViolation:
  $7FF97F0A3147


If comment out cthreads from the uses the exception is:


An unhandled exception occurred at $7F21B71F5147:
EAccessViolation:
  $7F21B71F5147
  $7F21B71F751B
  $7F21B71F769C
  $7F21B746BFFF


If run with gdb (and cthreads):


Heap dump by heaptrc unit
355 memory blocks allocated : 948252/948432
355 memory blocks freed : 948252/948432
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072
[Thread 0x75991700 (LWP 2874) exited]
[Thread 0x76192700 (LWP 2873) exited]
[Thread 0x77fe3740 (LWP 2869) exited]
Cannot find user-level thread for LWP 2875: generic error


Any idea how to detect what/where is the source of the exception?

I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.

Gabor


FB3API_IBX.tar.gz
Description: GNU Zip compressed data
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus