Re: [Lazarus] Lazarus The Complete Guide
On Tue, 23 May 2017, Salvatore Coppola via Lazarus wrote: Hi to all the authors, is in program a new edition of the guide? Yes, but no date is set. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow
On 23.05.2017 20:43, Ondrej Pokorny via Lazarus wrote: What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? I meaned - to use in _inside_ LCLIntf.SetForegrondWindow, not making new LCL func. -- Regards, Alexey -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow
On 2017-05-23 18:43, Ondrej Pokorny via Lazarus wrote: What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? For anything running under X11 I have never had a problem with XRaiseWindow(xapplication.display, FWinHandle); So Qt and GTK could you that, if they aren't already. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow
On 23.05.2017 19:38, Alexey via Lazarus wrote: What do you think about using this rare API [beginning from WinXP] in LCLIntf fnction? It will make LCL function work more stable: window will always go to foreground. I used it in CudaText. It works. https://github.com/Alexey-T/CudaText/blob/master/app/fix_focus_window.pas What are the equivalents for Qt, Qt5, Gtk2, Carbon, Cocoa? Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Use rare Win32 API in LCLIntf.SetForegroundWindow
What do you think about using this rare API [beginning from WinXP] in LCLIntf fnction? It will make LCL function work more stable: window will always go to foreground. I used it in CudaText. It works. https://github.com/Alexey-T/CudaText/blob/master/app/fix_focus_window.pas -- Regards, Alexey -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Lazarus The Complete Guide
Hi to all the authors, is in program a new edition of the guide? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Order of events: TEdit / TListBox
Thanks, https://bugs.freepascal.org/view.php?id=31900 Please open an issue about it and I'll take a look on it. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Order of events: TEdit / TListBox
On 2017-05-23 14:27, kapibara via Lazarus wrote: So the behaviour is inconsistent between platforms, and also inconsistent within the same control (TListBox) depending on what item is selected. I believe I have reported that back in 2006 already. If not the same component, then one of the list components, but I think it was TListBox too. I'm afraid LCL is full of inconsistencies like that - between platforms and between widgetsets. If memory serves me correctly, I was told it wouldn't be fixed, because such behaviour is dependent on the underlying GUI toolkit, so developers just have to figure out a work-around in their applications. Our code became an IFDEF mess, and shortly afterwards fpGUI was born. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Order of events: TEdit / TListBox
On 05/23/2017 03:27 PM, kapibara via Lazarus wrote: On 05/23/2017 09:18 AM, zeljko wrote: It's normal. If you click onto listbox (OnMouseDown of listbox triggers), TEdit looses focus and triggers OnExit() Thanks for the reply. Yes, on Windows, Lazarus and Delphi 7 behave the same. Except that Delphi 7 doesn't have the ListBox.SelectionChange event: Lazarus Win platform: Edit.Exit always fires before ListBox.OnClick (and OnSelectionChange), no matter if the ListBox item is selected or not. Good. Though I would not expect SelectionChange to fired since there is no change in selection? Problem is with Lazarus Linux GTK2. Events behave the *opposite* to Windows Lazarus and Delphi 7: 1) SelectionChange does not fire when clicking an already selected item. I might be wrong, but thats good I think and the windows implementation bad? 2) Edit.Exit fires BEFORE ListBox.OnClick if selecting and already selected ListBox item. Good. 3) Edit.Exit fires AFTER ListBox.SelectionChange and ListBox.OnClick if selecting a different ListBox item than the currently selected one. Bad. So the behaviour is inconsistent between platforms, and also inconsistent within the same control (TListBox) depending on what item is selected. Please open an issue about it and I'll take a look on it. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Order of events: TEdit / TListBox
On 05/23/2017 09:18 AM, zeljko wrote: It's normal. If you click onto listbox (OnMouseDown of listbox triggers), TEdit looses focus and triggers OnExit() Thanks for the reply. Yes, on Windows, Lazarus and Delphi 7 behave the same. Except that Delphi 7 doesn't have the ListBox.SelectionChange event: Lazarus Win platform: Edit.Exit always fires before ListBox.OnClick (and OnSelectionChange), no matter if the ListBox item is selected or not. Good. Though I would not expect SelectionChange to fired since there is no change in selection? Problem is with Lazarus Linux GTK2. Events behave the *opposite* to Windows Lazarus and Delphi 7: 1) SelectionChange does not fire when clicking an already selected item. I might be wrong, but thats good I think and the windows implementation bad? 2) Edit.Exit fires BEFORE ListBox.OnClick if selecting and already selected ListBox item. Good. 3) Edit.Exit fires AFTER ListBox.SelectionChange and ListBox.OnClick if selecting a different ListBox item than the currently selected one. Bad. So the behaviour is inconsistent between platforms, and also inconsistent within the same control (TListBox) depending on what item is selected. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Show value hints while debugging fills screen - patch
I find debugging value hints (TurboPowerIProDsgn installed, "Show value
hints while debugging") useful but annoying when the hint becomes so big
it covers the variable being checked or even fills the screen; on single
monitor systems the only way to close the hint is to scroll down to the
variable link. Especially annoying when the mouse-over was inadvertent.
The following code illustrates the problem:
program HugeHintProblem;
var
HugeHintVar: array[1..100, 1..100] of byte;
i, j: Integer;
begin
for i := 1 to 100 do
for j := 1 to 100 do
HugeHintVar[i,j] := random(255);
{ Break on the next statement and mouse-over HugeHintVar - The hint
will fill the screen (this may take some time).}
HugeHintVar[1, 1] := 56;
end.
The following patch seems to fix the problem, limiting the hint span
from the left side of the variable and one line below to the bottom
right corner of the editor in undocked mode, and to the bottom right
corner of the IDE in docked mode.
Index: components/ideintf/idehelpintf.pas
===
--- components/ideintf/idehelpintf.pas(revision 55056)
+++ components/ideintf/idehelpintf.pas(working copy)
@@ -383,6 +383,8 @@
end;
procedure DoHtml;
+ var
+MaxWidth, MaxHeight: Integer;
begin
if HintFont<>nil then
HintRenderWindow.Font := HintFont;
@@ -397,10 +399,16 @@
ms.Free;
end;
HtmlHelpProvider.ControlIntf.GetPreferredControlSize(NewWidth,NewHeight);
+MaxWidth := Screen.ActiveForm.Left + Screen.ActiveForm.Width -
ScreenPos.x;
+MaxHeight := Screen.ActiveForm.Top + Screen.ActiveForm.Height -
ScreenPos.y;
if NewWidth <= 0 then
- NewWidth := 500;
+ NewWidth := 500
+else if NewWidth > MaxWidth then
+ NewWidth := MaxWidth;
if NewHeight <= 0 then
- NewHeight := 200;
+ NewHeight := 200
+else if NewHeight > MaxHeight then
+ NewHeight := MaxHeight;
HintRenderWindow.HintRectAdjust := Rect(0, 0, NewWidth, NewHeight);
if MouseOffset then
HintRenderWindow.OffsetHintRect(ScreenPos)
I have tested this with windows XP, 7 and 8.1, Lazarus V1.64, V1.65 and
trunk, and with two monitors in various configurations
I tried to register an account on the bug tracker twice, but the link in
the confirmation email leads to an APPLICATION ERROR #1902 in Mantis,
complaining about an invalid confirmation URL
Regards
Russell
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Order of events: TEdit / TListBox
On 05/23/2017 04:15 AM, kapibara via Lazarus wrote: Some more findings. Under Windows, the Edit.Exit event fires before both SelectionChange and OnClick no matter what item you select. It's normal. If you click onto listbox (OnMouseDown of listbox triggers), TEdit looses focus and triggers OnExit() Plus under Windows, SelectionChange fires even though an item might already be selected which it doesn't under Linux GTK2. Under both environments, the Click event fires after SelectionChange.. OnClick() is passed after OnMouseDown() + OnMouseUp(), so it's normal. When you press one item with mouse selection changes (click isn't triggered yet), releasing mouse triggers MouseUp and Click(). zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
