Re: [Lazarus] How to restore anchor docking manager in the IDE?
Am 13.07.2021 um 20:10 schrieb John Landmesser via lazarus: I don't remember exactly what i've done in the past. Ok, it's a pity. I used anchordockingdsgn package for a long time and today i thought: what happens if i drag "project inspector" for example to another position ... bad idea(!!) Things got worse as i tried to restore the initial settings of this package. Reinstalled the package, read the wiki ... no success, but then with google i found the mentioned Lazarus forum thread: close all windows except source editor and then rearrange all windows. I never use such a workaround to rearrange the windows. And thats IMO the problem. I know what I have to do to get my layout back, but I don't know what other people try to do. Would be usefull if there was something like restore default settings?! Yes, this seems a good idea! Can you make a bug report and assign it to me?! Thank you Michl -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to restore anchor docking manager in the IDE?
Am 13.07.2021 um 14:07 schrieb John Landmesser via lazarus: Hi, i just "ruined" layout of the anchor docking manager in the IDE. Can you explain, what you have done? I can only fix/work on things, I'm aware about. Maybe you have disabled the option "Show headers". Only with this option enabled you can drag and drop the windows (click on header, hold header and move window). Michl Reinstall the package does not restore the default layout and pulling for example object inspector does not help. I would expect the IDE would show where to place the object inspector by painting a frame where it would sit if i stop dragging?! Tipps are welcome ... John Landmesser -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Ping
Now, this mail is arrived Am 08.06.2021 um 19:43 schrieb Michael W. Vogel via lazarus: Ping -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Ping
Ping -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TScrollBox.ScrollInView method does not work for nested child controls
Am 01.05.2021 um 01:08 schrieb Leyba Bronstain via lazarus: I found that the ScrollInView method doesn't scroll the scrollbar to a "hidden" control unless its parent is a scrollbox but another component that lies on the scrollbox. Fixed in Trunk revision 65078 with code from https://forum.lazarus.freepascal.org/index.php/topic,54354.msg404204.html#msg404204 Michl -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] I found an AnchorDockingDsgn package bug?
Am 14.06.2019 um 23:51 schrieb leyba bronstain via lazarus:
After installing the AnchorDockingDsgn package for Win7 x64, I noticed
a strange IDE behavior. If you dock any other window to the Source
Code Editor in the manner shown in the figure, then it becomes
impossible to close any tab of the Source Code Editor using the mouse
(using the shortcuts, the tab is closed correctly). It's a bug?
See more here:
https://forum.lazarus.freepascal.org/index.php/topic,45728.0.html
Yes, I can confirm that problem.
The SourceEditor doesn't have a default PopupMenu, it is created on
MouseUp. So the AnchorDockingPageControl is opening its PopupMenu. I
could recreate the problem in a simple app.
Imho a simple workaround could be to create a dummy PopupMenu for
SourceEditor, something like the added patch.
Can you please open a bug report on Mantis?!
Michl
Index: ide/sourceeditor.pp
===
--- ide/sourceeditor.pp (revision 61401)
+++ ide/sourceeditor.pp (working copy)
@@ -657,6 +657,7 @@
private
FNotebook: TExtendedNotebook;
FBaseCaption: String;
+FDummyPopupMenu: TPopupMenu;
FIsClosing: Boolean;
FSrcEditsSortedForFilenames: TAvlTree; // TSourceEditorInterface sorted
for Filename
TabPopUpMenu, SrcPopUpMenu, DbgPopUpMenu: TPopupMenu;
@@ -6557,6 +6558,8 @@
OnTabEndDrag := @NotebookEndDrag;
ShowHint:=true;
OnShowHint:=@NotebookShowTabHint;
+FDummyPopupMenu := TPopupMenu.Create(Self);
+PopupMenu := FDummyPopupMenu;
{$IFDEF IDE_DEBUG}
debugln('[TSourceNotebook.CreateNotebook] D');
{$ENDIF}
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TESTERS NEEDED / ALL PLATFORMS / COPY AND PASTE / Re: Copy to clipboard from synedit
Am 15.07.2018 um 12:27 schrieb Martin Frb via Lazarus: Please try with rev 58530 Tested all your requests on 64bit Windows 7 with 32bit Lazarus and OpenOffice. No problems, work fine here! Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] WARNING: TResourceCacheItem.IncreaseRefCount 1000 TFontHandleCache
Am 16.02.2018 um 22:16 schrieb Vojtěch Čihák via Lazarus: Hi, don't you know what does this output mean(in Console In/Output, not in Messages): WARNING: TResourceCacheItem.IncreaseRefCount 1000 TFontHandleCache ? Thanks, V. Please create a minimal example and report to mantis bugtracker. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE menu editor - icons in dropdown are grayed
Am 20.12.2017 um 10:29 schrieb AlexeyT via Lazarus: Please add a minimal example. OS Ubuntu 17.4, here is example proj. Do you mean 17.04? Weird, I just checked with Ubuntu 16.4 and can't see the problem. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE menu editor - icons in dropdown are grayed
Am 20.12.2017 um 08:46 schrieb AlexeyT via Lazarus: Not sure it is bug. i added icon to mainmenu top items, and to dropdown items (e.g. File and File/Open). Menu editor: icon for File is yellow, ok. icon for File/Open is grayed, not ok. must be same icon. gtk2, Laz trunk. Which OS? I tested 64bit Linux Mint KDE 17.3, Lazarus 1.9.0 r56784M FPC 3.0.2 x86_64-linux-gtk2 and Windows 7, the icons for subitems aren't grayed. Please add a minimal example. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help for solving an ActiveX regression crash bug
Am 25.09.2017 um 11:07 schrieb Juha Manninen via Lazarus: On Sun, Sep 24, 2017 at 9:20 PM, Michael W. Vogel via Lazarus wrote: I added the relavant info on bugtracker. Thanks. You found the InterfacePropertyEditor and issue: https://bugs.freepascal.org/view.php?id=31324 as the culprit. There was a similar issue: https://bugs.freepascal.org/view.php?id=24570 which I tried to solve a long time ago but failed. It is now marked as resolved together with the other issue. I hope Mattias and/or Michal Gawrycki can look at the issue at some point. The main problem is, if the Component = nil for TInterfacePropertyEditor.AllEqual the result was changed to true. Thatswhile there is a AV. But I don't know, why for Component := GetComponentReference there is the component nil?! Also (maybe the same reason) AV by freeing the component. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help for solving an ActiveX regression crash bug
Am 24.09.2017 um 15:41 schrieb Michael W. Vogel via Lazarus: Am 24.09.2017 um 11:41 schrieb Juha Manninen via Lazarus: Regarding issue: https://bugs.freepascal.org/view.php?id=32375 Could somebody please provide a debugger backtrace and preferably a patch to fix it. Also finding out which revision caused the regression would be helpful. http://wiki.freepascal.org/How_do_I_create_a_bug_report#Regression_caused_by_a_certain_revision There are other similar issues which will likely be solved at the same go, like: https://bugs.freepascal.org/view.php?id=32030 My own development system has Linux and I will not configure a Windows system now. A long ToDo list already... I'll have a look at this issue and report. I added the relavant info on bugtracker. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Help for solving an ActiveX regression crash bug
Am 24.09.2017 um 11:41 schrieb Juha Manninen via Lazarus: Regarding issue: https://bugs.freepascal.org/view.php?id=32375 Could somebody please provide a debugger backtrace and preferably a patch to fix it. Also finding out which revision caused the regression would be helpful. http://wiki.freepascal.org/How_do_I_create_a_bug_report#Regression_caused_by_a_certain_revision There are other similar issues which will likely be solved at the same go, like: https://bugs.freepascal.org/view.php?id=32030 My own development system has Linux and I will not configure a Windows system now. A long ToDo list already... I'll have a look at this issue and report. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TabControl stopped working from rev. 55890
Am 22.09.2017 um 09:46 schrieb Michael W. Vogel via Lazarus: Am 22.09.2017 um 09:42 schrieb Torsten Bonde Christiansen via Lazarus: Due to a change in wincontrol.inc regarding TabStop the TabControl has stopped working completely. It causes an A/V during create. Yes, I'll fix it. There is a old workaround, I'll see, if it is needed further. https://bugs.freepascal.org/view.php?id=32455 I fixed the issue in revision 55892 and removed the old workaround. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TabControl stopped working from rev. 55890
Am 22.09.2017 um 09:42 schrieb Torsten Bonde Christiansen via Lazarus: Due to a change in wincontrol.inc regarding TabStop the TabControl has stopped working completely. It causes an A/V during create. Yes, I'll fix it. There is a old workaround, I'll see, if it is needed further. https://bugs.freepascal.org/view.php?id=32455 Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] crDrag cursor is now 2x bigger
Am 07.09.2017 um 15:57 schrieb Michael W. Vogel via Lazarus: This is a inconsistency between Linux and Windows. While on Windows the cursors are scaled after the DPI setting is changed, on Linux the cursors stays small. The cursors taken from the system are further small. The cursors taken from resourse are wrongly scaled. Damn, I'm wrong. This was the behaviour after switching from 120 to 196DPI. Seems so, not all settings were correctly switched. After a restart of that OS, revision 55794 works correct here (all cursors scaled, just crNo is to little, see test app on bugtracker): 64bit Linux Mint KDE 17.3 Lazarus 1.9.0 r55794 FPC 3.0.2 x86_64-linux-gtk2 Well, I think lets discuss it here: https://bugs.freepascal.org/view.php?id=32385 Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] crDrag cursor is now 2x bigger
Am 07.09.2017 um 09:09 schrieb Ondrej Pokorny via Lazarus: Michl added high-resolution cursors recently. Obviously Gtk2 picks up the wrong size. Win32 works fine. This is a inconsistency between Linux and Windows. While on Windows the cursors are scaled after the DPI setting is changed, on Linux the cursors stays small. The cursors taken from the system are further small. The cursors taken from resourse are wrongly scaled. Will see. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] fpReport released
Am 20.08.2017 um 21:16 schrieb Michael Van Canneyt via Lazarus: Missing dependency. I added it, please update and try again. It's compiled now. Thank you very much! Let's test your report :) Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] fpReport released
Am 20.08.2017 um 20:35 schrieb Michael Van Canneyt via Lazarus: fpreport has been committed to FPC SVN: packages/fcl-report. It should compile on windows, linux, freebsd and darwin. I just tried to compile a clean fpc: make distclean make all install INSTALL_PREFIX=%FpcPath% PP=%BootStrapCompilerPath%\ppc386.exe I got this error: Start compiling package fcl-report for target i386-win32. Compiling fcl-report\BuildUnit_fcl_report.pp Compiling .\fcl-report\src\fpreportstreamer.pp Compiling .\fcl-report\src\fpreporthtmlparser.pp Compiling .\fcl-report\src\fpreport.pp Compiling .\fcl-report\src\fpjsonreport.pp Compiling .\fcl-report\src\fpreportjson.pp Compiling .\fcl-report\src\fpreportdb.pp External command "c:/32fpc311/fpc/compiler/ppc386.exe -Twin32 -FUfcl-report\unit s\i386-win32\ -Fuc:\32fpc311\fpc\rtl\units\i386-win32\ -Fuc:\32fpc311\fpc\packag es\fcl-base\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\fcl-res\units\i386-win 32\ -Fuc:\32fpc311\fpc\packages\rtl-objpas\units\i386-win32\ -Fuc:\32fpc311\fpc\ packages\fcl-image\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\pasjpeg\units\i 386-win32\ -Fuc:\32fpc311\fpc\packages\paszlib\units\i386-win32\ -Fuc:\32fpc311\ fpc\packages\hash\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\fcl-xml\units\i3 86-win32\ -Fuc:\32fpc311\fpc\packages\fcl-pdf\units\i386-win32\ -Fuc:\32fpc311\f pc\packages\fcl-json\units\i386-win32\ -Fufcl-report\src -Ur -Xs -O2 -n -di386 - dRELEASE -XX -CX -viq fcl-report\BuildUnit_fcl_report.pp" failed with exit code 1. Console output: Target OS: Win32 for i386 Compiling fcl-report\BuildUnit_fcl_report.pp Compiling .\fcl-report\src\fpreportstreamer.pp Writing Resource String Table file: fpreportstreamer.rsj Compiling .\fcl-report\src\fpreporthtmlparser.pp Compiling .\fcl-report\src\fpreport.pp Writing Resource String Table file: fpreport.rsj Compiling .\fcl-report\src\fpjsonreport.pp Writing Resource String Table file: fpjsonreport.rsj Compiling .\fcl-report\src\fpreportjson.pp Writing Resource String Table file: fpreportjson.rsj Compiling .\fcl-report\src\fpreportdb.pp fpreportdb.pp(22,32) Fatal: Can't find unit db used by fpreportdb Fatal: Compilation aborted The installer encountered the following error: Compilation of "BuildUnit_fcl_report.pp" failed make[2]: *** [smart] Error 1 make[2]: Leaving directory `c:/32fpc311/fpc/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `c:/32fpc311/fpc' make: *** [build-stamp.i386-win32] Error 2 Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Anchoring problem with ScrollBox and Panels
Am 07.06.2017 um 09:52 schrieb Gabor Boros via Lazarus: Your example work as expected. If resize the form panel resized properly. As it should. I simply wanted to show you, what happen when you anchor the bottom of a panel: Sizing of form, sizes the panel. The same, as in all your test projects before: Sizing of ScrollBox1, sizes Panel2. I tried to accomplish the task in a different way. Attached a new example. Bottom of Panel2 anchored to bottom of ScrollBox. This works. Top of Panel2 anchored to bottom of Panel1. When resize the form top of Panel2 is moving Why? Top of Panel2 why not stay with bottom of Panel1? You have anchored it to center. The center of Panel2 is now the center of ScrollBox1. See http://wiki.lazarus.freepascal.org/Anchor_Sides#Example_3 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Anchoring problem with ScrollBox and Panels
Am 06.06.2017 um 19:39 schrieb Gabor Boros via Lazarus: The attached example contains a form with a ScrollBox on it with three Panels in it. Height of Panel1 is static, height of Panel2 depend on the size of Form/ScrollBox, height of Panel3 can be modifiable by the user. In the example a simple OnClick emulate the variable height feature of Panel3. So, start the example, modify (or not) size of the form, then click on Panel3. I got a "Position range overflow..." error. What I doing wrong or is this a bug? I can tell you here the same as in the related bug report https://bugs.freepascal.org/view.php?id=30617, this isn't a bug it is not happy design. You want that the scrollbox height is increased, but then the Panel2 height is increased too. Simple remove anchored bottom of Panel2 and the loop is gone. As you wrote in bug report: "Thank you for the example but do not do what I want.", please explain better, what you exactly want (step by step, when a user change the height of Panel3, what should happen). Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus RC1 - Test finding at TSQLQuery.RecordCount
Am 19.05.2017 um 13:40 schrieb Joe via Lazarus: I am using a TSQLQuery named Query on a Form. Code Completion offers a property 'RecordCount' for Query. See first Screen Shot 'Offer.png'. But the "Liste der überwachten Ausdrücke" says: "Type TSQLQUERY has no component named RECORDCOUNT". Maybe the hint is a bit misleading (imho "property" would be better than "component"), but yes, "currently the debugger does not support any method execution. Therefore only properties that refer directly to a variable can be inspected", see also: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Properties Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] German lazarus forum down
Am 15.05.2017 um 22:57 schrieb Michael Fuchs via Lazarus: wie ihr vielleicht schon gemerkt habe, ist das deutschsprachige Lazarusforum schon wieder nicht erreichbar. Leider kann ich noch keine Prognose abgeben, wann wir wieder online sind. Na hoffentlich müssen wir keine 300$ in Bitcoins spenden... Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Menu editor unstable? - stack trace
Am 09.05.2017 um 15:15 schrieb Michael Van Canneyt via Lazarus: Hi, I manage to reliably reproduce it ! 1 Open attached project. 2 Double click MainMenu1 to edit 3 Under MenuItem5, delete MenuItem14,13,12,11 (I use the - button in the menu editor) 4 The last menu item under MenuItem5 is then 'Action3' 5 Add new menu item (I click 'add menu item' below the Action3 item) 6 Click on Action 3 7 Click on the newly added (in step 5) MenuItem11 --->> BOOM Never fails. The delete step 3 is important. Without that, I don't get a crash. I then tested deleting a single item instead of 4 items as described above, then I also get a crash. So as soon as a delete is performed - boom... Thank you for your exact explanation and test project! But sorry again, again I don't get it. I have tested here: 64bit Linux Mint 18.1 Cinnamon, GTK2 version 2.24.30, Lazarus 1.9.0 r54844 FPC 3.0.2 x86_64-linux-gtk2 64bit Linux Mint 17.3 KDE, GTK2 version 2.24.23, Lazarus 1.9.0 r54826 FPC 3.0.2 x86_64-linux-gtk2 64bit OpenSuse Leap 42.2 KDE GTK2 version 2.24.31, Lazarus 1.9.0 r54809 FPC 3.0.2 x86_64-linux-gtk2 64bit Windows 7, Lazarus 1.9.0 r54844 FPC 3.0.2 x86_64-win64-win32/win64 Maybe it is a problem with your GTK2 version? Maybe it is a problem with your OS? Maybe it was fixed in meantime? Maybe you have a broken installation of Lazarus? Maybe it is a timing problem (as my development pc was out of order, I bought a relativ fast Core I5, so I'm not fast enough to click)? Maybe it is better to open a bugreport about that issue? Then we can better gather informations about it. Is there anybody else how can create a crash with the test project and the steps above? Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Menu editor unstable? - stack trace
Am 08.05.2017 um 15:54 schrieb Michael Van Canneyt via Lazarus: OK. It seems clear to me that something is being freed which should not yet be freed: WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? This indicates to me that an unforeseen order of events is happening ? As far as I know, there is a global call to free components once the message processing is finished ? Well, I hope you can reproduce it... Sorry, I don't get it. After over two hours of testing with 64bit Linux Mint 18.1 Cinnamon and Lazarus 1.9.0 r54833M FPC 3.0.2 x86_64-linux-gtk2, with new or saved projects, without or with AnchorDockingDsgn / Sparta_DockedFormEditor, I'm not able to create a crash. I tried this steps and around: - Open project - Select a popup menu (there are several) - Double click to edit - Select menu item 1 - Immediatly select menu item 2 If you want, you can add a minimal example and explain every single step again, what you do, to create a crash. Then, I'll test again, but for now, I don't know what to do more. What Lazarus revision are you using? Do you have installed AnchorDockingDsgn, Sparta_DockedFormEditor or something similar? Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Menu editor unstable? - stack trace
Am 08.05.2017 um 15:09 schrieb Michael Van Canneyt via Lazarus: I managed to produce a stacktrace. Hopefully this, combined with the stacktrace at the end is sufficient to solve the issue. Michael. (gdb) cont Continuing. WARNING: TShadowItem.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event? Thread 1 "lazarus" received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x009fd6f2 in SETSELECTEDSHADOW (this=0x7fffe02077b0, PREVSELECTEDITEM=0x7fffe37107c0, CURSELECTEDITEM=0x7fffe03c1e80, VIADESIGNER=false) at ../designer/menueditor.pp:1663 #2 0x009fd49d in SETSELECTEDMENUITEM (this=0x7fffe02077b0, AMI=0x7fffe03c1e80, VIADESIGNER=false, PREVWASDELETED=false) at ../designer/menueditor.pp:1617 #3 0x00a02673 in MOUSEDOWN (this=0x7fffe9371e10, BUTTON=MBLEFT, SHIFT=8, X=73, Y=8) at ../designer/menueditor.pp:2590 #4 0x005b29f8 in DOMOUSEDOWN (this=0x7fffe9371e10, MESSAGE=..., BUTTON=MBLEFT, SHIFT=0) at include/control.inc:2242 #5 0x005b2e61 in WMLBUTTONDOWN (this=0x7fffe9371e10, MESSAGE=...) at include/control.inc:2375 #6 0x00436562 in DISPATCH (this=0x7fffe9371e10, MESSAGE=0) at ../inc/objpas.inc:602 #7 0x005b28fd in WNDPROC (this=0x7fffe9371e10, THEMESSAGE=...) at include/control.inc:2202 #8 0x005a580c in WNDPROC (this=0x7fffe9371e10, MESSAGE=...) at include/wincontrol.inc:5396 #9 0x007722ac in DELIVERMESSAGE (TARGET=0x7fffe9371e10, AMESSAGE=0) at lclmessageglue.pas:112 #10 0x0066c191 in DELIVERMESSAGE (TARGET=0x7fffe9371e10, AMESSAGE=0) at gtk2/gtk2proc.inc:3702 #11 0x0067aec6 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x3aced90, EVENT=0x3624ea0, AWINCONTROL=0x7fffe9371e10) at gtk2/gtk2callback.inc:2137 #12 0x0067a5c8 in GTKMOUSEBTNPRESS (WIDGET=0x32d2b80, EVENT=0x3624ea0, DATA=0x7fffe9371e10) at gtk2/gtk2callback.inc:1899 #13 0x76c8cafc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #14 0x76916fa5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x76928fc1 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x769317f9 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x7693208f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x76da48cc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #19 0x76c8b294 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #20 0x76c8b64b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #21 0x7775bc4c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #22 0x76640197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x766403f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7664049c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x004fc6ec in APPPROCESSMESSAGES (this=0x77f75230) at gtk2/gtk2widgetset.inc:2338 #26 0x0049435d in HANDLEMESSAGE (this=0x77f74bf0) at include/application.inc:1276 #27 0x004948ac in RUNLOOP (this=0x77f74bf0) at include/application.inc:1413 #28 0x006585a6 in APPRUN (this=0x77f75230, ALOOP=...) at include/interfacebase.inc:54 #29 0x00494850 in RUN (this=0x77f74bf0) at include/application.inc:1401 #30 0x00420127 in main () at lazarus.pp:145 (gdb) cont Continuing. TApplication.HandleException Access violation Stack trace: $ $009FD49D line 1617 of ../designer/menueditor.pp $00A02673 line 2590 of ../designer/menueditor.pp $005B29F8 line 2242 of include/control.inc $005B2E61 line 2375 of include/control.inc $00436562 line 602 of ../inc/objpas.inc $005B28FD line 2202 of include/control.inc $005A580C line 5396 of include/wincontrol.inc $007722AC line 112 of lclmessageglue.pas $0066C191 line 3702 of gtk2/gtk2proc.inc $0067AEC6 line 2137 of gtk2/gtk2callback.inc $0067A5C8 line 1899 of gtk2/gtk2callback.inc $76C8CAFC As I've made some bug fixes for the Menueditor last time, I tried to reproduce this error. Till now I wasn't able to reproduce it on Lazarus Trunk revision 54826 with FPC 3.0.2 on Windows 7, 10, OpenSuse 42.2 KDE GTK2 or Linux Mint 17.3 KDE GTK2. I currently install on a VM a 64bit Linux Mint 18.1 Cinnamon (your OS?!), to test the issue there. I'll report. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TForm.GetFormImage is broken?
The method TWinControl.PaintTo doesn't refresh the RawImage.Data, like it is done in TRasterImage.Draw. It isn't only a issue for the method GetFormImage. I fixed it in revision 53790. As far as I can see, there are no additional calls done, as the needed one (e.g. TWin32WidgetSet.RawImage_FromBitmap is only called one time before saving to stream). Hope, it works now as expected. If not, please report. Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TForm.GetFormImage is broken?
Am 27.12.2016 um 11:17 schrieb Balázs Székely via Lazarus: But Delphi does not require the bmp.Canvas.Changed. Shouldn't it be added to the GetFormImage internally to make this simple code Delphi-compatible? That's a good idea. The current behavior is confusing. See comments: http://bugs.freepascal.org/view.php?id=25448 Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] New high DPI features in 1.7
Am 10.12.2016 um 12:40 schrieb Ondrej Pokorny via Lazarus: On 10.12.2016 11:13, zeljko wrote: Is there any chance to have TApplication property which will disable Scaled (even when Scaled=True) for complete application (Design and RunTime) ? I thought about it already but I haven't solved one issue: how should that property be reliably read both in design and run time? We'd need some kind of project option (in .lpi) that would automatically set the corresponding TApplication property in .lpr - something like TApplication.Title (that can be set in project options). I am still not 100% sure about it, but it may be the only one solution. Any suggestions are welcome! Oh, then we get a global switch to enable/disable high DPI support OS independet (as defined in the Windows manifest - and then this value has to take care about that switch). Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Patch for ShortcutToText, array
Am 10.12.2016 um 11:45 schrieb Juha Manninen via Lazarus: On Thu, Dec 8, 2016 at 11:11 PM, Alexey via Lazarus wrote: Juha, what do you think about this big patch. http://mantis.freepascal.org/view.php?id=30992 I was hoping Michl and Bart take care of it. ... I will apply your patch if it works. It breaks some locals for german keys (other languages, I've not tested till now). I'll have a look at it and report. But it will take a while - sorry. Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
Am 14.11.2016 um 15:08 schrieb zeljko via Lazarus: +1 for new Options property instead of separate property. zeljko +1 Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6
Am 04.11.2016 um 08:35 schrieb Ondrej Pokorny via Lazarus: TextHint in Lazarus should be OS independent (it was decided long time ago). Thats fine! The TextHint implementation should be completely rewritten. It shouldn't use the text property but paint the TextHint onto the control by itself. Windows can do that and Qt/Gtk2 should be able to do it as well (IIRC - I talked about it with zeljko in Lazarus ML). For that some new virtual paint method (PaintAfterInterface) should be introduced - that would call the widgetset dependent PaintAfterInterface method. Thats also fine. So it can be implemented for TComboBox (as in Delphi) too. So for now, the speed and paint issue should be fixed, later the redesign. Thank you for your hints. Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6
Hi, After looking a bit at this issue http://bugs.freepascal.org/view.php?id=30851, I have some general questions. Is the behaviour of Delphi more important or a user friendly one? 1. TextHint in Delphi is theme dependent and OS dependent (available for Windows Vista, Windows 7, or later), in Lazarus not. What is the desired behaviour? 2. TextHint in a TMemo isn't shown in Delphi (of course the property TextHint is there and can be written and readed). In Lazarus it is sometimes shown but not correct removed, if a line is inserted by code. Should TextHint generally not be shown in a TMemo or the bugs removed? Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6
Am 03.11.2016 um 00:27 schrieb Luiz Americo Pereira Camara via Lazarus: Can you try with TextHint <> ''? Seems that will need to add an aditional check for lines UpdateCount Thank you for the hints! I add a new patch (just for Windows now), it takes care about this issues. There is one nasty allocation, I have to remove, so it is not the final work. It will takes a while (or someone else has a better solution). Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Memo.Lines.Add seems to be slow with Lazarus 1.6
I have made a bug entry and added there a first patch (its not the final one, but its late here now). Can you check, if it fixes the speed on your OS too (I have tested only Windows 7 for now)? http://bugs.freepascal.org/view.php?id=30851 Thank you for your feedback! Kind regards Michl Am 02.11.2016 um 20:26 schrieb Graeme Geldenhuys via Lazarus: On 2016-11-02 18:43, Luca Olivetti via Lazarus wrote: Maybe it's overkill, but it's necessary under windows, Welcome to the benefits of custom components where you can easily outperform native components. Just curious, has anybody tried the TMemo of LCL-CustomDrawn widgetset? I know the LCL-CustomDrawn components are still far from being useful in real-world applications, but how does that TMemo perform against the other native widgetsets? Or is the regression in some LCL TMemo common code? I tried LCL-fpGUI with Bernd's code snippet, and it is dog slow, but that is because Memo.Lines.BeginUpdate..EndUpdate doesn't do anything to the fpGUI rendering performance. fpGUI has "native" Memo.BeginUpdate..EndUpdate methods (at widget level - irrespective of the internal list class used). I'll see if I can fix LCL-fpGUI's TMemo in that regard, so it calls the appropriate BeginUpdate..EndUpdate. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Option to deactivate always open Menu Editor
Am 09.10.2016 um 21:43 schrieb Juha Manninen via Lazarus: I am puzzled, what is the purpose of the now uncommented TMenuItemsPropertyEditor? As its comment says "property editor for TMenuItem properties. Invokes the parent menu's component editor." ... but the whole idea was NOT to invoke it. I didn't know, if it is needed elsewhere. You deactivated it for the current issue, but it doesn't make any difference. So I activated again. Anyway, if it isn't needed somewhere else, it can be removed. Sorry for the trouble. Am 09.10.2016 um 22:20 schrieb Juha Manninen via Lazarus: The OnDesignerSetSelection handler was only added to GlobalDesignHook when the form was created but it was never removed. That was another bug. Ah OK, I doesn't think of that. I tested r53087 and it works fine here. Thank you very much! Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Option to deactivate always open Menu Editor
Hi Juha, I tested the issue a while and I can't see any unwanted side effects, so I added a patch here: http://bugs.freepascal.org/view.php?id=30712 See you Kind regards Michl Am 07.10.2016 um 16:31 schrieb Juha Manninen via Lazarus: On Fri, Oct 7, 2016 at 4:42 PM, Michael W. Vogel via Lazarus wrote: I checked r53075 (32bit FPC trunk r34637, Windows 7). The behaviour here isn't changed. Always, I select a MenuItem in object inspector, the menu editor is opened. A other curious thing (I don't know if it is wanted), in its Caption stands: "Form1.MainMenu1.MenuItem1 - OnClick: is not assigned". Uhhh! I am sure it worked then but not any more. The menu editor is now shown through some unknown route. It does not use neither of these: procedure ShowMenuEditor(aMenu: TMenu); function MenuDesigner: TMenuDesigner; If this isn't a wanted behavoiur, I can check this issue this evening, if you want. Yes please if you have time and energy. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Option to deactivate always open Menu Editor
Hi Juha, I checked r53075 (32bit FPC trunk r34637, Windows 7). The behaviour here isn't changed. Always, I select a MenuItem in object inspector, the menu editor is opened. A other curious thing (I don't know if it is wanted), in its Caption stands: "Form1.MainMenu1.MenuItem1 - OnClick: is not assigned". If this isn't a wanted behavoiur, I can check this issue this evening, if you want. Kind regards Michl Am 07.10.2016 um 12:33 schrieb Juha Manninen via Lazarus: I deactivated it in r53074. Please test. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
Am 05.10.2016 um 10:00 schrieb Michael Schnell via Lazarus: Maybe an additional property defining the behavior of the appropriate callbacks for all those controls to be "UserAction" "ProgramAction" or "Both", defaulting to the Delphi behavior might be a good idea. -Michael Thats sounds interesting! A lot of newbies errors rest upon this, I often can see in the forums, e.g. endless loops: TFooControl.OnChange (called by user) -> change TBarControl.Text TBarControl.OnChange (called by code) -> change TFooControl.Text TFooControl.OnChange (called by code) -> ... Of cause, it would be a big job (for all widgetsets), to implement such a property (FOnChange is inserted on various class places), but IMHO it isn't impossible to do it for useful controls. But I'm not sure, would such a property be accepted by the Lazarus developer? Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
Am 03.10.2016 um 22:53 schrieb Bart via Lazarus: OT reply: I can't see you on contributors list? Bart No, I'm sorry, I'm not a Lazarus developer. If I understand Bart right, he had a fix for that bug report, Not yet ;-) Bart Ah, OK. I inserted the solution from Ondrej in my current project and it really seems to be the better approach. If there is no other opinion to that topic, you can ignore my initial hint. Now, there is only the gap of Lazarus and Delphi compatibility versus Lazarus consistency. I don't know, how many other Lazarus user use the TPageControl.OnChange event in the same manner as I do. If no one else, there is no barrier to change it to Delphis behaviour ;) Offtopic: Maybe is Delphis behaviour not really consistent. For example, TEdit.OnChange is fired, if the TEdit.Text is changed by user or code. Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPageControl OnChange calling issue
Am 03.10.2016 um 19:34 schrieb Ondrej Pokorny via Lazarus: Isn't TTabSheet.OnShow enough for you? Ondrej Interesting approach! I've just tested it in one of my apps and yes, it seems to work too. So this could be a obviously better solution for me. Thank you for that hint! Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] TPageControl OnChange calling issue
Hi, we want to discuss a bug report http://bugs.freepascal.org/view.php?id=25554 here, not in Mantis (hope, I understand Bart right). Today, the TPageControl.OnChange event behave different in Lazarus than in Delphi. In Delphi it is only called (so the bug report), if the user change the page. In Lazarus it is also called, when the page is changed by code. I like (need) the behaviour in Lazarus, cause I mostly use blank TPageControls, with dynamic added pages and filled with dynamic created TFrames (created on demand). So for me it isn't important, if the user select a page or it is selected by code, I need the OnChange event to create or initialize the TFrame. If I understand Bart right, he had a fix for that bug report, but than the behaviour now is gone. I would prefer a option like nboCallPageChangeByCodeSelection to keep the current behaviour (so it doesn't break Lazarus code). A other possibility would be a new event like OnChangePage (as a replacement for the current Lazarus TPageControl.OnChange). I wouldn't throw the current (in my eyes: better) behaviour away. What is your opinion? Kind regards Michl -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
