[Lazarus] Transparent TPanel reloaded
I've found quite a few posting regarding a transparent TPanel and somehow nothing fits. All I need is to place controls on a panel and let it look like there were directly on its parent. I don't want to create a component for this. The panel is colored clDefault and placed on a form colored clDefault, too. Using ParentColor := TRUE, on Ubuntu 12 with GTK2 the form is $F2F5F7 and the panel is much darker. I guess, I finally found a solution, but I don't really understand it: BevelInner := bvNone; BevelOuter := bvNone; Caption := ''; BorderStyle := bsNone; ParentColor := False; IF Assigned (Parent) THEN Color := Parent.GetRGBColorResolvingParent; The final line is funny. I thought, just GetRGBColorResolvingParent should work, but it doesn't. Any idea? Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] German umlauts in component names
On Mon, Apr 4, 2016 at 5:48 PM, Ondrej Pokorny wrote: > On 04.04.2016 12:05, Special wrote: > >> BTW too: Some English words became part of german, like 'Computer' und >> 'Button'. We don't say "Elektronische Rechenmaschine" any longer, and more >> and more german book authors say "Button" instead of the strange >> "Schaltfläche". Yes, I confess, I used "Schaltfläche" too in some of my >> early books three decades ago, but now I don't. >> > > I see a good progress here. The first step was using "Computer" instead of > "Elektronische Rechenmaschine", the second step was using "Button" instead > of "Schaltfläche". The next logical step is to teach pupils from the very > beginning that the programmer's language is English. > > English is part of the compulsory education from very early classes, > AFAIK. They definitely can understand the very limited vocabulary needed to > write programs. The word "Close" is used in event names, after all. So I > really don't see a gain using "SchließenButton" instead of "CloseButton". Agreed. For everything related to programming, using Non-English words is a non-sense as you can only lose. How could "SchließenButton" make anything better, when you can't invoke "Fenster.Schließen" anyway? The only case when national identifiers make sense is when they come from a business domain. Translation of e.g. financial business terms is not exactly something a programmer should do, so either the customer supplies English terms or I leave them as they are. Except for removing diacritics. This is fortunately easy for the languages I use. I wonder what I'd do if I used a language not based on a Latin alphabet. Then I might end up with a 賣Button. Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] How do events come into the glib event queue?
Our Lazarus-GTK2 application crashes due to a GTK event whose target has been freed. My problem is that I can see only the place where this happens and the data has already been overwritten. *What I need is the place where the event was generated or enqueued.* I thought it'd be gtk2msgqueue.pp, but TGtkMessageQueue.AddMessage gets never called before the crash. A side question: What is TGtkMessageQueue good for? Below is the stacktrace... I'm sure it's not helpful for finding out the bug, it just illustrates my problem. Regards, Martin. #0 g_type_check_instance_is_a (type_instance=0x85e58f0, iface_type=139661072) at gtype.c:3967 #1 0x0820f28a in GLIB2_G_TYPE_CHECK_INSTANCE_TYPE$POINTER$LONGWORD$$BOOLEAN () #2 0x08200345 in GTK2_GTK_CHECK_TYPE$POINTER$LONGWORD$$BOOLEAN () #3 0x082009c6 in GTK2_GTK_IS_WIDGET$POINTER$$BOOLEAN () #4 0xb78d8000 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb77ed641 in g_idle_dispatch (source=source@entry=0x85ee160, callback=0x82e3430 , user_data=0x85e58f0) at gmain.c:5321 #6 0xb77f0bb9 in g_main_dispatch (context=0x85305d0) at gmain.c:3066 #7 g_main_context_dispatch (context=context@entry=0x85305d0) at gmain.c:3665 #8 0xb77f0ecf in g_main_context_iterate (context=context@entry=0x85305d0, block=block@entry=0, dispatch=dispatch@entry=1, self=0x8508000) at gmain.c:3736 #9 0xb77f0f83 in g_main_context_iteration (context=0x85305d0, may_block=0) at gmain.c:3797 #10 0x081d8462 in TGTK2WIDGETSET__APPPROCESSMESSAGES (this=) at ./gtk2/gtk2widgetset.inc:2326 -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus versions in git
Hi Graeme! On Thu, Dec 17, 2015 at 5:58 PM, Graeme Geldenhuys < mailingli...@geldenhuys.co.uk> wrote: > On 2015-12-17 15:09, Martin Grajcar wrote: > > I wonder what commit corresponds to Lazarus 1.4.2. > > > With the limitation in mind (as mentioned in my other replies), I pushed > a couple of release tags to Github. That's nice, thank you! However, after having executed git reset --hard v1.4.2 && make clean && make I've got Lazarus 1.5. As I understand it (or as I hope), there are just odd versions in the repository and switching to 1.5 was the very first done after releasing 1.4. So taking this commit and setting the version to 1.4.2 should be all I need? Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Lazarus versions in git
I wonder what commit corresponds to Lazarus 1.4.2. There's an official git mirror at https://github.com/graemeg/lazarus.git, but I can't see there neither branches nor tags corresponding to releases (except for some oldies up to v0.9.28.2). We want to stick with 1.4.2 for now, but apply some patches (both official fixes and ours). Regards Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] D7 compatibility in component definition concerning TPage
I've tried to unify some Lazarus and D7 sources and succeeded except for
one thing:
TYPE TMyForm = CLASS(TForm)
{$IFDEF FPC}
SomePage: TPage;
{$ENDIF}
END;
Delphi parses it wrongly and always offers to remove the declaration.
I don't need the declaration in L, but removing it led to a class not found
error.
While in LFM the form looks like
object SomeBook: TNotebook
object SomePage: TPage
end;
end;
there's just
object SomeBook: TNotebook
object TPage
end;
end;
in Delphi. I modified it to look like L, but it changed nothing.
Any idea?
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Forwarding events/messages
On Wed, Nov 4, 2015 at 6:07 PM, Ondrej Pokorny wrote: > On 04.11.2015 17:54, Martin Grajcar wrote: > > I'd like to forward a TLMVScroll message to the parent component as a > workaround for controls preventing parents from receiving mouse wheel > events (I couldn't find out how to let the parents receive them). > > The problem is that the handler is > > PROCEDURE TWhatever.WMVScroll(VAR Message : TLMVScroll); > > and I need to put it in > > FUNCTION SendMessage(HandleWnd: HWND; Msg: Cardinal; WParam: WParam; > LParam: LParam): LResult; > > Or am I missing a more suitable procedure? Why is there no > > SendMessage(Message : TLMVScroll); > > which would do exactly this? > > > There is TControl.WndProc, but don't call it directly if you don't know > what and why you are doing it. > I found it in the meantime... and the usage seems to be obvious (if the parent instance and message type checks pass, then send it to the parent, otherwise call inherited). The tiny problem is that it does nothing at all. My workaround is to scroll manually, like > > TScrollingWinControl(Parent).ScrollBy (0, ScrollAmount); > > but this feels stupid as it duplicates the ScrollAmount computation. > > > AFAIK forwarding of messages works only on Windows, > This could be the reason for my code doing nothing. :( > so if you need it cross-platform, you will have to use > "TScrollingWinControl(Parent).ScrollBy (0, ScrollAmount);" in any case. So > this should be the correct way to do it. > That's ugly like hell and I can only guess the ScrollAmount, which means that it can scroll much more or less than when the mouse it outside of my TControl. Anyway, thank you! Martin. > - Zeljko, correct me if I am wrong, you are the specialist here :) > > Ondrej > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Forwarding events/messages
I'd like to forward a TLMVScroll message to the parent component as a workaround for controls preventing parents from receiving mouse wheel events (I couldn't find out how to let the parents receive them). The problem is that the handler is PROCEDURE TWhatever.WMVScroll(VAR Message : TLMVScroll); and I need to put it in FUNCTION SendMessage(HandleWnd: HWND; Msg: Cardinal; WParam: WParam; LParam: LParam): LResult; Or am I missing a more suitable procedure? Why is there no SendMessage(Message : TLMVScroll); which would do exactly this? My workaround is to scroll manually, like TScrollingWinControl(Parent).ScrollBy (0, ScrollAmount); but this feels stupid as it duplicates the ScrollAmount computation. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hiding a component by changing its parent
On Mon, Aug 24, 2015 at 4:43 PM, Mattias Gaertner wrote: > On Mon, 24 Aug 2015 16:29:49 +0200 > Martin Grajcar wrote: > > > In code I'm working on, I've found a pattern like > > > > PROCEDURE HideIt; > > BEGIN > > SomeComponent.Visible := FALSE; > > SomeComponent.Parent := SELF; > > SomeComponent.Visible := TRUE; > > END; > > > > PROCEDURE ShowIt(NewParent: TForm); > > BEGIN > > SomeComponent.Visible := FALSE; > > SomeComponent.Parent := NewParent; > > ...some more stuff... > > SomeComponent.Visible := TRUE; > > ...some more stuff... > > END; > > > > I can't really see what it's good for. I guess, the idea was to preserve > > the widget, but the widget seems to get freed immediately in the first > > line. It comes from D7 or older. Does it make sense on Lazarus 1.4 using > > GTK+? > > No. > Simply do "SomeComponent.Parent := NewParent;". > Thank you for the information! Simplifying helped to get rid of a crash on Linux http://bugs.freepascal.org/view.php?id=28840 but there's still an event-related problem on Mac. Could someone tell me more about what problem may get solved by using the more complicated stuff? Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Problem with PDF printing
I've just found out that our printing with Lazarus 1.4.2 on 64 bit Linux doesn't work, e.g., it always produces a nearly empty PDF file (2.6 kB) with CUPS PDF printer and an empty page on a real printer with a message stating Error Name: undefined Offending Command: -nan Operand Stack: 53.641 It works on 32 bit Linux (and Mac) and it works with Lazarus 1.2.6, which we used before. Printing uses Fastreport 4.15.13. and there's no problem with the preview, it's just the real printing what fails. There's no exception, seemingly just garbage gets produced somewhere. All in all, it looks like a pretty tough problem, so I wonder if someone could give me some good advice how to approach it. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Hiding a component by changing its parent
In code I'm working on, I've found a pattern like PROCEDURE HideIt; BEGIN SomeComponent.Visible := FALSE; SomeComponent.Parent := SELF; SomeComponent.Visible := TRUE; END; PROCEDURE ShowIt(NewParent: TForm); BEGIN SomeComponent.Visible := FALSE; SomeComponent.Parent := NewParent; ...some more stuff... SomeComponent.Visible := TRUE; ...some more stuff... END; I can't really see what it's good for. I guess, the idea was to preserve the widget, but the widget seems to get freed immediately in the first line. It comes from D7 or older. Does it make sense on Lazarus 1.4 using GTK+? Whenever there's a focused TextField in SomeComponent, there's a segment violation on Linux after HideIt. It looks like an event (lost focus?) gets delivered to its already freed widget. Any thoughts? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Printing BitMap on OSX crashes
Hi Jesus, On Sat, Aug 1, 2015 at 7:08 AM, Jesus Reyes A. wrote: > > > The problem occurs because the bitmap is being freed before > Printer.EndDoc. It is at this point that the bitmap data is used, but > because it was already freed an AV occurs. I have actually fixed the > problem, but in my current implementation resources are only be freed at > program end. Which is not good if somebody are printing a lot. So I have > not committed the fix, I have another plan and will try again soon. > > In the mean time, the workaround it's easy (this is not the fix I > mentioned before which would patch the LCL+Printer support). Just create > the bitmap before Print.BeginDoc and free it after Print.EndDoc. That > should work. > it does, thanks a lot! Maybe you can help me with this: How can I get the debugger (lazarus/gdb) show the C code? All I get for the innermost frames is an address and assembler. No idea what to install (and Google really didn't help). Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Crash on OSX because of postponed double click processing
Our application crashes on OSX because of the event processing in function CarbonWindow_MouseProc(ANextHandler: EventHandlerCallRef; at lcl/interfaces/carbon/carbonprivatewindow.inc:329 if Postpone then begin PostponedDown := True; PostponedDownMsg := TLMMouse(Msg.Message); Result := CallNextEventHandler(ANextHandler, AEvent); end else begin ... end; // interactive design if (EventKind = kEventMouseDown) and Assigned(Widget.LCLObject) and ((csDesigning in Widget.LCLObject.ComponentState) or (Widget is TCarbonDesignWindow)) and (GetCarbonMouseButton(AEvent) = 1) then When double clicking on a custom component of ours, an ancestor of the component gets hidden and something else gets shown. Unfortunately, this hiding seems to happen in the call to CallNextEventHandler. During this the Widget gets freed, its Widget.LCLObject overwritten by some non-sense (e.g. $), and Widget.LCLObject.ComponentState crashes. This doesn't happen on Linux. 1. Is the a bug in Carbon or are we doing something wrong? I don't yet understand how our hiding code exactly works. 2. What's the best fix? Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] GetParent returning Self
In /usr/share/lazarus/1.2.6/lcl/interfaces/carbon/carbonprivatewindow.inc:299 (CarbonWindow_MouseProc ) there's the following code while Assigned(Widget) and not Widget.IsEnabled do begin // Here we need to avoid an endless loop which might occur in case // GetParent returns the same widget that we passed lTmpWidget := TCarbonWidget(CarbonWidgetset.GetParent(HWND(Widget))); if lTmpWidget = Widget then Break; Widget := lTmpWidget; end; In our application, it indeed happens somehow, that the condition lTmpWidget = Widget holds. This test helps to break the infinite cycle, but function TCarbonWidgetSet.GetParent(Handle: HWND): HWND; in /usr/share/lazarus/1.2.6/lcl/interfaces/carbon/carbonwinapi.inc:1794 gets also used from elsewhere, namely from /usr/share/lazarus/1.2.6/lcl/include/winapi.inc:432 function GetParent(Handle : HWND): HWND; which gets used from C code handling the event loop. It looks like there's a similar problem happening there, an endless loop keeping the CPU busy and the application dead. As a workaround, I appended if Result = Handle then Result := 0; to TCarbonWidgetSet.GetParent but this feels hacky. My questions are: 1. Am I right assuming that a windows having itself as parent is always wrong? 2. Is there a simple way how to find where this happens? I know it's not in in TCarbonWidgetSet.SetParent. 3. Is my workaround correct? Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Printing BitMap on OSX crashes
Hi Jesus, On Wed, Jul 1, 2015 at 10:52 PM, Jesus Reyes A. wrote: > On Tue, 30 Jun 2015 05:55:43 -0500, Martin Grajcar > wrote: > > Hello, > > apologies for reposting, but I can't see in the archives (and have > received no answer). > > Are attachments forbidden here? I'm given you a link instead: > https://dl.dropboxusercontent.com/u/4971686/bitmap-crash.demo.zip > > Regards, Martin. > > On Thu, Jun 25, 2015 at 10:57 AM, Martin Grajcar > wrote: > >> My trivial Lazarus 1.4 application (and also our real application) crash >> whenever it prints a TBitMap on MAC. It happens in >> _platform_memmove$VARIANT$sse4 it tries to execute MOVDQA >> and I thought it was an alignment problem, but it isn't. >> >> I'm attaching my rather confusing demo. It does nothing but printing and >> seems to work fine on Linux, but crashes on OSX. Commenting out the >> StretchDraw prevents the crash. I have currently no access to the MAC, so I >> apologize for not including a minimal example. >> > > > I can reproduce it, and although the AV is easily fixed it seems printing > bitmaps under Mac OS X it currently broken (loading a bitmap from a file > doesn't produce AV but it not working anyway). I'm sure it used to work > because I have PDF file generated using TPrinter and CUPS-PDF at some point. > I haven't a chance to try it yet. Just in case it's non exactly trivial, how can the AV be fixed? I was only accessing the MAC over a bad connection, which made pretty everything complicated. I'm also sure it used to work. > Please submit a report so it wont be forgotten. > http://mantis.freepascal.org/view.php?id=28455 Regards, Martin. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Printing BitMap on OSX crashes
Hello, apologies for reposting, but I can't see in the archives (and have received no answer). Are attachments forbidden here? I'm given you a link instead: https://dl.dropboxusercontent.com/u/4971686/bitmap-crash.demo.zip Regards, Martin. On Thu, Jun 25, 2015 at 10:57 AM, Martin Grajcar wrote: > My trivial Lazarus 1.4 application (and also our real application) crash > whenever it prints a TBitMap on MAC. It happens in > _platform_memmove$VARIANT$sse4 it tries to execute MOVDQA > and I thought it was an alignment problem, but it isn't. > > I'm attaching my rather confusing demo. It does nothing but printing and > seems to work fine on Linux, but crashes on OSX. Commenting out the > StretchDraw prevents the crash. I have currently no access to the MAC, so I > apologize for not including a minimal example. > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
