Re: [Lazarus] Bug in Add requirements dialog on MacOS.
I think there's already an issue for that: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39500 but creating a new bug report won't hurt. On Tue, Aug 9, 2022 at 12:24 PM Michael Van Canneyt wrote: > > > On Tue, 9 Aug 2022, Dmitry Boyarintsev via lazarus wrote: > > > Is it an owner drawn list? > > if I look in packager/addpkgdependencydlg.pas, it seems so, yes. > > Michael. > -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Bug in Add requirements dialog on MacOS.
Is it an owner drawn list? On Tue, Aug 9, 2022 at 11:26 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Hi, > > The 'Add requirement' dialog from the project editor on Mac OS > has a serious defect in the package list. See attached screenshot :-) > > I think a previous Lazarus version had the same problem in the IDE install > packages dialog. > > Should I report this in the bugtracker, or is it a known problem ? > > Michael.-- > ___ > 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] How to convert Delphi program with TRichEdit?
On Thu, Dec 9, 2021 at 5:23 AM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > If i remember correct TRichMemo won't be usable on Linux. > According to Bo's needs (showing colored Hex values) RichMemo will work just fine for Linux. (Both Qt and Gtk2) thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to convert Delphi program with TRichEdit?
On Thu, Dec 9, 2021 at 5:23 AM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > If i remember correct TRichMemo won't be usable on Linux. > To a certain extent, yes - not all features are available thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] How to convert Delphi program with TRichEdit?
On Wednesday, December 8, 2021, Bo Berglund via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Is there some non-standard package I could install (from OLPM or similar) > in > order to get it working again? > you might want to try TRichMemo it provides some sort of compatibility with TRichEdit https://wiki.freepascal.org/RichMemo#TRichEditForMemo thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
On Wed, Nov 11, 2020 at 3:31 PM Zoë Peterson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Personally I need the new behavior for any TCustomControl descendant, so > I'd put most of the code in TCocoaWSCustomControl, but we have our own > TUiTreeView/TUiCustomControl classes already, so I can add the extra > configurability we'd need there. > I'd suggest to address the issue in the same manner as NSCell-based vs NSView-based tables were. Just add another complication condition into Cocoa-widgetset. The use of NSViualEffectView cannot be hard in Cocoa, as LCL claims to support back to 10.5.8 (or at least 10.6) (There are still some PowerPC Lazarus users) The biggest concern I'd have with it being pushed into LCL proper is > that FillRect(clWindow) doesn't look right. The NSViualEffectView > changes color based on the average color of the desktop wallpaper behind > the window and shifts as you move the window around, so none of the > NSColors can match it. I had to adjust our owner draw functions to not > rely on drawing an opaque rectangle to clear/overwrite things, but it > wasn't too bad. > This is actually a LCL change, rather than Cocoa change. What you might want to do is to add another Widgetset compatibility flag (TLCLCapability) to indicate on how the background of TreeView should/should not be drawn. Using fancy effects is becoming a new norm (for any platform), so it might be handy in future for others (i.e. Qt5) One might argue that TLCLCapability is not the right place for that, and instead Themes class should be used. I personally don't have an opinion about that. After all, you're dealing with a problem that surpassed Win9x User Interface :) Thus, it's not a surprise for LCL not to have enough information to address the problem. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] RegisterWSComponent documentation?
The "logical" hierarchy of TWSxxx classes, drives the run time "virtual" composition. TWSCustomTreeView inherits from TWSCustomControl. When "building" an actual (interface) class in run-time, the code tracks every method declared at TWSCustomControl. If the method is overridden by any platform-descendant class (i.e. TCocoaWSCustomTreeVierw), then the run-time class will get the method from the descendant. Otherwise the platform-class (i.e. TCocoaWSCustomControl) method is used. If platform-class doesn't implement a method, the actual method (of TWSCustomControl) would be used. As a result, the runtime built class "emulates the hierarchy" of TCocoaWSCustromTree -> TCocoaWSCustromControl -> ... even though the actual hierarchy is TCocoaWSCustromTree -> TWSCustromTree TCocoaWSCustromControl -> TWSCustromControl It's not nice, but it works. There are three drawbacks due to use of such approach: * a complicated run-time "building" code * "inherited" call should not be used in TPlatformWSxxx methods. Instead of using inherited, an actual TPlatformWSParentClass should be used instead. * FPC verify method call (-CR) check cannot be used with LCL. (since it the check would always fail in run-time built classes) What you want to do, are the following things: 1) Declare TWSFancyTreeView, as a descendant from TWSTreeControl 2) Declare TUITreeView (LCL control), it can be a descendant from TTreeView 3) Add an implementation TCocoaWSFancyTreeView descendant from (TWSFancyTreeView). 4) In CocoaWSFactory, have a call to RegisterWSComponent( TUITreeView, TCocoaWSFancyTreeView ); that should do the trick. thanks, Dmitry On Tue, Nov 10, 2020 at 4:28 PM Zoë Peterson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Is there any documentation on how RegisterWSComponent works with > creating classes at runtime? > > I'm specifically looking at TTreeView and TCustomControl, which both > have WS classes, TWSTreeView and TWSCustomControl, and widgetset > specific subclasses, TCocoaWSTreeView and TCocoaWSCustomControl. It > looks like it's creating new classes at runtime that somehow combine > TCocoaWSTreeView and TCocoaWSCustomControl together, but it's not clear. > > If I have my own class (TUiTreeView) and I want to register a subclass > of my own to customize some behavior, should TUiCocoaWSTreeView descend > from TCocoaWSTreeView or TCocoaWSCustomControl? Does it matter? If I > have a TUiCocoaWSCustomControl too, which has a bunch of behavior I want > to share, can I have TUiCocoaWSTreeView descend from that? Does the > answer change if I add a new virtual method in TUiCocoaWSCustomControl? > > This is an issue for me because on macOS 10.14 and later, treeviews > should use an NSVisualEffectView for their background rather than using > a plain fillRect(clWindow). I have that working in our own wrapper > classes, but I'm not sure if I'm doing something dangerous. I would > love to submit the above back to the LCL for inclusion in stock Lazarus, > but to allow descendants to hook it properly, I'd want a virtual method > in TCocoaWSCustomControl that TCocoaWSTreeView could override, and I > assume that isn't supported. > > Thanks, > Zoë Peterson > Scooter Software > > -- > ___ > 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] Proposal: Allow Umlaute and Accented Characters in Identifiers
On Fri, Jul 3, 2020 at 12:44 PM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Having educational purposes in mind, can variable masking be > achieved through IDE itself, rather than the compiler. > Yes, i do realize that it might get worse when it comes to debugging, where the same masking technique will have to be used. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Proposal: Allow Umlaute and Accented Characters in Identifiers
On Fri, Jul 3, 2020 at 10:08 AM Special via lazarus < lazarus@lists.lazarus-ide.org> wrote: > on a Elementary School near Heidelberg the nine-years-old pupils learn > programming with Delphi 10.3 Community Edition. In one of the programs > they use 'Type ZimmerType = (Küche, Wohnzimmer, Schlafzimmer);", > Having educational purposes in mind, can variable masking be achieved through IDE itself, rather than the compiler. If a character outside of ANSI range is met within an identifier, IDE would replace it with something else. So, instead of having "Küche" the source code would look like "K_Ache". (the next character would be replaced with _B, _C ..and so on) It doesn't have to be done on the fly, it could be done before starting the compilation. There are two benefits with this approach: * no changes are needed for the compiler. (works with any version) * the language rules of capitalization can be followed thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Checkbox behaviour on Mac ?
On Mon, Apr 13, 2020 at 6:55 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > As I said, a stock Lazarus 2.0.6 install. From the about dialog, it seems > to > be using carbon. > It does worth bug reporting. With macOS 10.16, the installer (2.0.8) might need to include both 32-bit carbon and 64-bit cocoa builds or have two separate installers. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Checkbox behaviour on Mac ?
it looks like Carbon build. is it? On Monday, April 13, 2020, Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Hi, > > The checkbox in Lazarus 2.0.6 is almost unusable in at least 2 cases: > - Object inspector. > On average, I must click 3 to 5 times to get the result I need. > - in the online package manager > > See attached screenshots. > > In both cases the checkbox disappears in the row where the mouse cursor is > located. Kind of difficult to check something then. Clicking is also a > haphazard > experience. > > This is a stock Lazarus 2.0.6. Am I the only one experiencing this ? has > this been reported yet ? > if not: should I report it so it can please be included in 2.0.8 (if it is > not too late yet) > ? > > Michael. > -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Close all menu item ?
On Tue, Mar 24, 2020 at 5:39 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > To any normal human being, *Close All* means close *ALL*. > Why argue if you extend? Here's a little extension that makes "Close All" also "Close Project" (which make it act as "Close All") https://github.com/skalogryz/compatui Oddly enough, this is not my first IDE extension to make it more Delphi-like experience. https://wiki.freepascal.org/Manual_Docker https://github.com/skalogryz/clearrecent https://github.com/skalogryz/semax I should bring them all up together... thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Suddenly my appplication needs lbgtk-win32*.dll for Win10
On Fri, Mar 13, 2020 at 3:06 PM John Landmesser via lazarus < lazarus@lists.lazarus-ide.org> wrote: > just curiuos: > > I ave a little apllication that suudenly(?!!) needs ligtk-win32*.dll on > Windows 10. > > I think that's new and now i search for my changes that made this *.dll > needed! > Seems like you little application has been compiled with Gtk2 widgetset as a requirement. If you replace it with Win32 widgetset, you should not longer need any external dlls. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The future of the Lazarus IDE
On Mon, Nov 25, 2019 at 9:55 AM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Does it mean that LCL should let go all the native targets and become > > purely web-based? > > No, of course not. It "just" means implementing a web widgetset. > So the ultimate goal sounds like: * we need to implement WinAPI on the web-browser * Lazarus project structure needs to have means to differentiate the code between server and client-side? Wasn't there an attempt to start "web" widgetset before? or was is just limited to conversion of LFM to HTML?! thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The future of the Lazarus IDE
On Sat, Nov 23, 2019 at 5:26 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > The question whether Lazarus should be remade as an Electron style app? > Do you mean the IDE or all the API/widgets? > > The IDE. That implies the API/Widgets. > Does it mean that LCL should let go all the native targets and become purely web-based? Obviously from the backwards compatibility perspective it's an unlikely option. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The future of the Lazarus IDE
On Sat, Nov 23, 2019 at 5:04 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > This week in Be.Delphi, (and last week in DüsselDorf, Germany) TMS > Software has unveiled > a VS Code plugin: an Object Pascal RAD IDE. > what about this plugin: https://marketplace.visualstudio.com/items?itemName=alefragnani.pascal it seems like it has been out there for 2 years already. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The future of the Lazarus IDE
How are debugging capabilities in VS Code? thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] OSX 64 bit Cocoa + Catalina Installer
On Fri, Oct 25, 2019 at 11:12 AM Dan Star via lazarus < lazarus@lists.lazarus-ide.org> wrote: > /Compiler > "/Users/Dan/Development/FreePascal/fpc/bin/x86-64-darwin/fpc.sh" does > not support target x86-64-macos./ > "macos" platform target refers to Classic MacOS (MacOS 9), rather than MacOSX (or the modern name macOS) You might need to adjust platform target as well to "darwin" thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] OSX 64 bit Cocoa + Catalina Installer
On Fri, Oct 25, 2019 at 10:54 AM Dan Star via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The 'Build Lazarus" Information window appears OK for Cocoa but just > guessing; there is no way to copy this information to the clipboard nor > can I find a config file with it. > Try to build IDE from command-line, instead -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Showing selection on drawing under Cocoa
On Wed, Oct 16, 2019 at 4:33 PM C Western via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Am I missing something? How does the Cocoa toolkit expect this to be done? > I'm see 3 ways of doing that. 1) you just invalidate the needed rectangle lines (or the entire selected area) and do xor drawing on paint event. 2) you might want to try to play with "focusRing" settings of NSView. That requires Cocoa level access to the view. Not cross platform, obviously. 3) instead of drawing into the view itself, you might want to create a semi-transparent window or a control, to be at the top of the hierarchy. and draw a focus as an overlay. Obviously you want this window or control to ignore any keyboard or mouse events (not to interfere with underlying controls). The solution can be cross platform. Approach #1 seems to be the easiest at this point. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] OSX 64 bit Cocoa + Catalina Installer
On Tue, Oct 15, 2019 at 1:07 PM Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I have to search my backup drives for some of this code, but I believe I > also added a few extra classes to simplify some of the weirdness of Apple's > classes. > No need (to do it right now). I was wondering about the approach in general. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] OSX 64 bit Cocoa + Catalina Installer
I see. Thanks for the insight On Tuesday, October 15, 2019, Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > What I've done is created a reference counted class hierarchy to match > part of the Cocoa framework. > -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] OSX 64 bit Cocoa + Catalina Installer
On Tue, Oct 15, 2019 at 11:50 AM Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Personally I've implemented some OSX core classes in a manner that is much > more elegant manner that what's currently used in the Cocoa widgetset and > if time permits I may propose some of my changes that could push Cocoa > forward in a positive direction. > a preview or sneak peek available? -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] laz fixes 2.0 error on macOS cocoa
Try to update to r61642 On Mon, Jul 29, 2019 at 7:54 AM Andrea Mauri via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Dear All, > I updated my svn: > > URL: https://svn.freepascal.org/svn/lazarus/branches/fixes_2_0 > > Relative URL: ^/branches/fixes_2_0 > > Repository Root: https://svn.freepascal.org/svn/lazarus > > Repository UUID: 4005530d-fff6-0310-9dd1-cebe43e6787f > > Revision: 61640 > > > When I try to build lazarus I get: > > > Assembling (pipe) units/x86_64-darwin/wscomctrls.s > > customupdown.inc(467,10) Error: Identifier not found "FUseWS" > > treeview.inc(1878,16) Warning: Conversion between ordinals and pointers is > not portable > > treeview.inc(1935,22) Warning: Conversion between ordinals and pointers is > not portable > > comctrls.pp(4187) Fatal: There were 1 errors compiling module, stopping > > Fatal: Compilation aborted > > make[1]: *** [alllclunits.ppu] Error 1 > > make: *** [lazbuild] Error 2 > > > Best regards, > > Andrea > -- > ___ > 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] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Sun, Jun 9, 2019 at 8:59 AM Tobias Giesen via lazarus < lazarus@lists.lazarus-ide.org> wrote: > *** Terminating app due to uncaught exception > 'NSInternalInconsistencyException', reason: 'Cannot update for observer > for the key path > "mainWindow.representedURL" from , most > likely because the value for the key "mainWindow" has changed without an > appropriate KVO notification being sent. Check the KVO-compliance of the > TCocoaApplication class.' > Hello, I think there's a newer version of 10.15 available. Has anyone been able to test, IF this fix is still needed? thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Fri, Jun 14, 2019 at 9:16 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > There's one more thing about not overriding run method. > The event loop needs to be "terminated" and/or "stopped" in order for run > method to return. > If it doesn't return, Pascal unit finalization section won't run, and > that's not good. > A couple of things... I've modified the original patch changing terminate(nil) to stop(nil). That should take care of FPC friendly application termination. I've also started on COCOALOOPNATIVE, Which seems to be as a safest (and the most Cocoa friendly) approach. As it does use native- run method, yet it doesn't hi-jack the loop to call LCL event. https://wiki.freepascal.org/Cocoa_Internals/Application#Native_Loop_.28COCOALOOPNATIVE.29 However, at this point, COCOALOOPHIJACK is used by default thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cocoa: restoring windows order after reactivating the application
managed types are not allowed in objc objects. as FPC doesn't manage them there (yet). On Saturday, June 15, 2019, AlexeyT via lazarus < lazarus@lists.lazarus-ide.org> wrote: > https://github.com/graemeg/lazarus/commit/4a95f3638a6ec38e6c > 975164b52c9f6d54c7ad10 > > orderArray. Better make its type "array of TWinOrderLevel" and set its > size as SetLength(orderArray, N), and SetLength(orderArray, 0) to free. > This is better practice, more pascalish way to allocate array. > > -- > Regards, > Alexey > > -- > ___ > 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] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
There's one more thing about not overriding run method. The event loop needs to be "terminated" and/or "stopped" in order for run method to return. If it doesn't return, Pascal unit finalization section won't run, and that's not good. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
thanks, but it's already in the trunk On Thursday, June 13, 2019, Tobias Giesen via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Hello, > I found that the code must be corrected like this to avoid an Access > Violation if an event occurs before the aloop field is set. > > if Assigned(aloop) and not isrun then begin > isrun:=true; > Result:=nil; > aloop(); > terminate(nil); > exit; > end; > > Kind Regards, > > Tobias Giesen > Super Flexible Software GmbH & Co. KG > > > > On Wed, 12 Jun 2019 15:10:17 -0400 > Dmitry Boyarintsev via lazarus wrote: > > > On Wed, Jun 12, 2019 at 11:48 AM Zoë Peterson via lazarus < > > lazarus@lists.lazarus-ide.org> wrote: > > > > > "Swizzling" is the name for replacing the Objective C method pointers > > > using method_exchangeImplementations. It's not the same as > overriding it. > > > > > > > Quite an interesting technique. I'm quite confident it's being heavily > used > > for Javascript. > > (I guess it's somewhat natural for reflective languages to use it) > > > > Though I'd consider going that low level as a last resort, rather than a > > permanent solution. > > > > thanks, > > Dmitry > > Kind Regards, > Tobias Giesen > > Super Flexible Software GmbH & Co. KG > Buddenstr. 29-31 > 48143 Münster, Germany > www.superflexible.com > www.tgtools.com > > --- > Registered at register court Münster as HRA 9716 > Liability / general partner: TGTools GmbH > Registered at register court Münster as HRB 17763 > Directors: Tobias Giesen and Claudia Giesen > > -- > ___ > 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] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Wed, Jun 12, 2019 at 11:48 AM Zoë Peterson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > "Swizzling" is the name for replacing the Objective C method pointers > using method_exchangeImplementations. It's not the same as overriding it. > Quite an interesting technique. I'm quite confident it's being heavily used for Javascript. (I guess it's somewhat natural for reflective languages to use it) Though I'd consider going that low level as a last resort, rather than a permanent solution. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Wed, Jun 12, 2019 at 5:17 AM Marc Weustink via lazarus < lazarus@lists.lazarus-ide.org> wrote: > BTW, did we report this issue (of the running variable not set) to > Apple? Or is the below piece of code the way we should set it ourselves ? I didn't bug report the issue to Apple. The code provide can be called by LCL thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
Btw, I'd prefer to keep COCOALOOPOVERRIDE define in the source code. As neither approach is 100% clean, we'll pretty much want to have an option to switch between one another. The cleanest way however - is to modify LCL itself! So there would be no need to call a "runloop" procedure (thus no need to either hijack the event loop and/or override run) Obviously, on the condition that the widgetset CAN handle Pascal exceptions in LCL friendly manner. thanks, Dmitry On Wed, Jun 12, 2019 at 12:56 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus < > lazarus@lists.lazarus-ide.org> wrote: > >> David did the research on this one, but IMHO, this is a bad idea. As he >> said, the inherited run does more than just set _running before it >> starts calling nextEventMatchingMask; > > Yet Apple suggests that "run" method can be overridden. > That's very true, that Apple can add much more into "run" method and it > would be nice if we could use the code. > Yes, overriding "run" has its own risk of not being future compatible. > But I don't recall any flawless macOS update. On each new macOS version > there were some "LCL incompatible" changes anyway. > > >> that's is just the bit that causes an obvious crash. It's also poking >> around the implementation rather >> than relying on the public API, so it will be more likely to break again >> going forward. >> > Public API is actually refers to methods, not instance names. > Actually instance variable name are specifically should be named with > underscore in them > ( > https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html > ) > > >> If it's a problem to check isRunning every time through >> nextEventMatchingMask, and alternative with the same behavior would be >> to swizzle in the runloop variant before calling inherited run and >> switching it back once we get into it. >> > Switching back? how is it possible? > > I don't really like the idea of hijacking the event loop for quite a > simple reason. > The nextEventMatchingMask can be called for whatever event, and hijacking > can violate the conditions of the call. > (for example, if the method is called with a timeout, and LCL hijacks the > loop. Then it never returns withing specified time). > > We cannot be sure at what particular event, the hijacking would occur. > Today, there was a bug report, about crash in the hijacking approach > > https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420 > > The application written caused nextEventMatchMask to be called even prior > to Application.Init. > So eventually the method is as risky as overriding "run", and not a good > design. > > (for example: NSApplication might send a certain event to NSWindow. Until > the event has been processed it would leave some internal variables > uninitialized as well) > > thanks, > Dmitry > -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Tue, Jun 11, 2019 at 10:43 AM Zoë Peterson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > David did the research on this one, but IMHO, this is a bad idea. As he > said, the inherited run does more than just set _running before it > starts calling nextEventMatchingMask; Yet Apple suggests that "run" method can be overridden. That's very true, that Apple can add much more into "run" method and it would be nice if we could use the code. Yes, overriding "run" has its own risk of not being future compatible. But I don't recall any flawless macOS update. On each new macOS version there were some "LCL incompatible" changes anyway. > that's is just the bit that causes an obvious crash. It's also poking > around the implementation rather > than relying on the public API, so it will be more likely to break again > going forward. > Public API is actually refers to methods, not instance names. Actually instance variable name are specifically should be named with underscore in them ( https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueCoding/Compliant.html ) > If it's a problem to check isRunning every time through > nextEventMatchingMask, and alternative with the same behavior would be > to swizzle in the runloop variant before calling inherited run and > switching it back once we get into it. > Switching back? how is it possible? I don't really like the idea of hijacking the event loop for quite a simple reason. The nextEventMatchingMask can be called for whatever event, and hijacking can violate the conditions of the call. (for example, if the method is called with a timeout, and LCL hijacks the loop. Then it never returns withing specified time). We cannot be sure at what particular event, the hijacking would occur. Today, there was a bug report, about crash in the hijacking approach https://forum.lazarus.freepascal.org/index.php/topic,44930.msg323420.html#msg323420 The application written caused nextEventMatchMask to be called even prior to Application.Init. So eventually the method is as risky as overriding "run", and not a good design. (for example: NSApplication might send a certain event to NSWindow. Until the event has been processed it would leave some internal variables uninitialized as well) thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Tue, Jun 11, 2019 at 10:06 AM David Jenkins via lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> I looked at the assembly for NSApplication.run, there are a lot of things
> being called and set before the call to nextEventMatching... The
> .isRunning variable being one of them - which is read only and can't be
> set. It can be overridden (and is one of the suggested overrides) but
> unfortunately there are times, in other parts of the code, that they look
> directly at the ._running variable where the value of .isRunning is stored
> instead of calling .isRunning (look at NSApplication._setMainWindow).
> Which sets up a mismatch between what an overridden .isRunning method would
> return and what ._running is set to.
>
Let's back-up a little bit.
Can we actually try to set the value for the instance variable?
1) it's absolutely legal in Objective-C terms (object_getInstanceVariable,
object_setInstanceVariable).
2) its' absolutely legal in KVC term. (I can presume that KVC is pretty
much based on top of objc-run time. And this is how the entire Swift<->ObjC
binding works)
Can anyone try and modify TCocoaApplication.run to look like this. (If
you're using trunk, you'll need to have {$define COCOALOOPOVERRIDE} defines
in cocoadefines.inc}
procedure TCocoaApplication.run;
begin
self.setValue_forKey(NSNumber.numberWithBool(true),NSSTR('_running')); //
setting instance variable through KVC
isrun:=true;
aloop();
end;
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Tue, Jun 11, 2019 at 5:49 AM Tobias Giesen via lazarus < lazarus@lists.lazarus-ide.org> wrote: > the fix works fine! It does make sense, and maybe Apple changed > something in Catalina and they still need to update the documentation. > > The way aloop() is called now does look like a quick workaround, maybe > it is possible to find a better looking way to run it. Maybe there is a > different callback or method override where this can be called. But > since it works fine, I am quite happy already! > I wonder if it's related to the official support of UIKit. UIApplication doesn't suggest overriding of events handling (it only allows to "preview" an event before it has been executed by UIKit). (nothing mentioned in release notes though: https://developer.apple.com/documentation/macos_release_notes/macos_10_15_beta_release_notes ) The patch has been applied. I left the door open for the original implementation (with run method override). By the way, did anyone try 32-bit Carbon app (i.e. Lazarus)? :) thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
I'd actually encourage Tobias to try the patch at #35702 and see if it fixes the problem. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Mon, Jun 10, 2019 at 6:18 PM David Jenkins via lazarus < lazarus@lists.lazarus-ide.org> wrote: > In now. Mantis 35702 > While the research seems to be quite thorough, the following statement: "Error is caused because Cocoa currently doesn't run through base level NSApplication.run and thus appropriate ._isrunning flag is not set " contradicts Apple's documentation ( https://developer.apple.com/documentation/appkit/nsapplication?language=objc ) "...Methods to Override ... Override run if you want the app to manage the main event loop differently than it does by default. (This a critical and complex task, however, that you should only attempt with good reason.)" If the first statement is true, then run cannot and should not be overriden at all. thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Modal Window Crashes on Mac OS X 10.15 Beta (Catalina)
On Sun, Jun 9, 2019 at 11:31 AM Zoe Peterson via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I'll make sure it's submitted to the bug tracker on Monday. > Follow up! :) thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cocoa Widet Set Status
On Mon, Jun 3, 2019 at 4:05 PM Mattias Gaertner via lazarus < lazarus@lists.lazarus-ide.org> wrote: > popup menu does not work here. But I hardly need that. > Need more hints: https://bugs.freepascal.org/view.php?id=35225#c116395 thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mantis: cannot edit my comments
what happens if you move your mouse cursor over the message header (where the message author information is listed? Chrome browser: https://www.dropbox.com/s/wyytnge3i8qz4ap/editbuttons.gif?dl=0 If you still don't see them, then it might be as easy as providing additional rights to "Reporters" On Fri, Apr 26, 2019 at 3:29 PM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On Fri, Apr 26, 2019 at 8:50 PM AlexeyT via lazarus > wrote: > > > > > Cannot edit them anymore. No button at all. > > I filed a bugreport about it (in the Manits section of the bugtracker). > > Bart > -- > ___ > 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] Website/Mantis back online
Oddly enough Mantis 2.21 was released on April 20th https://mantisbt.org/bugs/changelog_page.php?project=mantisbt&version=2.21.0 On Sun, Apr 21, 2019 at 6:52 AM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > On 20/04/2019 23:36, Michael Van Canneyt via lazarus wrote: > > , Mantis has been updated to the latest version. > > There may be an issue with search being case sensitive > > https://forum.lazarus.freepascal.org/index.php/topic,45123.msg318408.html#msg318408 > -- > ___ > 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] Website/Mantis back online
On Sat, Apr 20, 2019 at 6:42 PM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > I can (if needs must) get used to the look. Maybe this would help? > https://github.com/mantisbt-plugins/MantisBT-Colorized +1 It does worth installation. perception of items is much more clear then the entire raw is colored to the status (as it used to be). Rather than a small little square. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE Ctrl+W key
On Mon, Mar 18, 2019 at 10:58 PM Martin Frb via lazarus < lazarus@lists.lazarus-ide.org> wrote: > History back should work after an codetools error. IIRC Ctrl-H, but I move > it to Alt-Cursor-Left. > The first time I hear about that thing. What's "History point"? how is it defined? -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE Ctrl+W key
On Mon, Mar 18, 2019 at 1:57 PM Mattias Gaertner via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Ctrl+Space always jumped to an error. > Although over the years codetools parser matured. So some syntax, that > was formerly skipped/ignored, now raises an error. Maybe you mean this? > I would think, this is exactly the problem. Though I'd expect the mature parser to be more tolerant to user errors and do some sort of self recovery. Also, I don't think me simply complaining about the "here and there" would help. However, sometimes I just cannot bug-report the issue, because restarting the IDE resolves the problem. Is there any sort of stand-alone code-tools log happening? Something that could be used for bug reporting? > IMO hiding an error is asking for trouble. > A good GUI must indicate somehow when the results are not reliable or > incomplete. That's what C-language developers are relying on. In Pascal world compilation is fast, so it will be quite a short time when the compiler would remind a developer about the error. (btw, the "slowness" retains even in modern faster languages. i.e. C#. It's not because the compiler is slow, but because an IDE is slow. Lazarus manages to keep very high performance) > For example by showing as first result a red line with the > error message, which when selected will jump to the error. > Then the user can deliberately choose to fix or ignore the error. > I hate my cursor to jump anywhere, when I'm asking for word-completion at a particular placement. As well as the concentration on the particular part of the code is lost. The error can be pretty far away, and returning to the where I was might take some time. (btw, due to aggressive jumping in the past. I.e. when Objective-P support was only introduced to code tools I taught myself to use bookmarks often. Just for a quick jump back to the line of code I was working at.) I guess that would substitute a good deal of word-completion. Although > word-completion is also much faster. > All in all, why can't both of them be the same thing? Typical single-form application template: procedure TForm1.FormCreate(Sender: TObject); begin For| end; Ctrl+Space produces: * FormCreate * FormIsUpdating * FormState * FormStyle ... Ctrl+W produces: * Forms * FormsCreate (how did it know?) * Form1 thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE Ctrl+W key
On Sun, Mar 17, 2019 at 7:35 PM Mattias Gaertner via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > > > > Ctrl+Space is for parseable Pascal files, Ctrl+W is for all other > > > files. > > > > > and what's the issue to have Ctrl+Space for both cases? > > Are you aware that if Ctrl+Space fails it jumps to the syntax error? > Yes. And it's irritating, because I do remember when Ctrl+Space used to work even with incomplete sources. I often trying to use Ctrl+Space to complete the word on incomplete sources. (because I don't remember an API, and I need a hint.). But instead of showing me a list of options, it just doesn't work or jumps somewhere else. (...and jumping can be turned off, yet it won't do anything useful). thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE Ctrl+W key
On Sun, Mar 17, 2019 at 4:58 PM Mattias Gaertner via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Ctrl+Space is for parseable Pascal files, Ctrl+W is for all other > files. > and what's the issue to have Ctrl+Space for both cases? -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Tell me, does this application exist?
On Sat, Jan 5, 2019 at 10:59 PM Anthony Walter via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The part that is the desktop service would be designed to support a list > of specific applications such as Krita, Gimp, Inkscape and so on (obviously > this list could be expanded). > > The part that is the Android tablet application would connect to the > desktop service and display what it is told by the desktop service, and > also forward stylus input to the desktop service. > https://play.google.com/store/apps/details?id=com.adobe.psmobile&hl=en_US -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Crowdfunding to speed up the development of pas2js in Lazarus Widgetset and fpDebug to FPC
On Fri, Dec 21, 2018 at 6:38 PM Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Good news :) Which platform did you use ? Do you still need contributions ? > > Patreon.com It's 4 USD a month! https://www.patreon.com/skalogryz -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Crowdfunding to speed up the development of pas2js in Lazarus Widgetset and fpDebug to FPC
On Friday, December 21, 2018, Michael Van Canneyt via lazarus < lazarus@lists.lazarus-ide.org> wrote: > > If we decide on using a crowdfunding platform, I would rather go for one > of the sites mentioned here: > > https://www.crowdfunding.com/ > I’ve been successful in establishing crowdfunding for cocoa development. Thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] editorconfig support
On Tue, Dec 4, 2018 at 10:36 AM Bart via lazarus < lazarus@lists.lazarus-ide.org> wrote: > Masks unit (/components/lazutis folder of Lazarus)? > This however assumes all strings are UTF8 and requires the LazUtf8 unit. Yep. That's the one I had on my mind but could not remember. Thanks -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] editorconfig support
On Wed, Nov 21, 2018 at 10:43 AM Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > if anyone is interested, I've started a support of editorconfig > https://github.com/skalogryz/editorConfig > for Pascal in general (which you can use in your editor project), > as well as Lazarus IDE extension > With the last revision made, the code currently satisfies 100% (191 of 191) editorConfig Core tests! The code doesn't depend on anything but RTL (classes, sysutils units). And some pieces are also written w/o RTL dependency. The specs of editorConfig require parsing of file masks, in a certain manner. Obviously, since all the tests are being completed, the code is working. But are there any Pascal libraries already available that can perform file masks parsing? As well as bash expression processing? Specifically Brace Expansion: https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus not starting anymore since -r59627 on MacOSX Mojava x86_64 cocoa
On Tue, Nov 27, 2018 at 5:25 AM Michael Ring via lazarus < lazarus@lists.lazarus-ide.org> wrote: > The last working version is -r59626 > Are you using docking? https://bugs.freepascal.org/view.php?id=34593 -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] editorconfig support
Hello, if anyone is interested, I've started a support of editorconfig https://github.com/skalogryz/editorConfig for Pascal in general (which you can use in your editor project), as well as Lazarus IDE extension thanks, Dmitry -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Forms.pp function error?
On Tue, Oct 16, 2018 at 1:29 PM AlexeyT via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Value $400 makes sense. > And also this must be changed then: > function KeysToShiftState(Keys: PtrUInt): TShiftState; > it uses same constants. > The value you're looking for is $2000 It's being used/supported by all current widgetsets -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Mandatory PopupParent (handle) for ShowModal
Hello, What's the logic behind forcing a modal window to have a popupparent (handle)? Even if a PopupParent form is not specified explicitly, LCL code would find one for a modal being opened. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Character spacing doubled in R58529 on MacOSX/Cocoa
You need to use 58531 On Sunday, July 15, 2018, Michael Ring via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > I today build Lazarus MacOSX/Cocoa from svn and realized that all > characters in the editor seem to have an extra space between each character. > > I did a little compiling of older SVN's and found out that the problem > appeared first in revision 58529. > > > This change in 58529 seems to kill the cat: > > > Index: lcl/interfaces/cocoa/cocoagdiobjects.pas > === > --- lcl/interfaces/cocoa/cocoagdiobjects.pas(revision 58528) > +++ lcl/interfaces/cocoa/cocoagdiobjects.pas(working copy) > @@ -559,6 +559,7 @@ >Win32Weight, LoopCount: Integer; >CocoaWeight: NSInteger; >FTmpFont: NSFont; > + IsDefault: Boolean; > begin >inherited Create(AGlobal); > > @@ -570,7 +571,18 @@ > // because otherwise the result is wrong in Mac OS X 10.11, see bug > 30300 > // Code used for 10.10 or inferior: > // FName := NSStringToString(NSFont.systemFontOfSize(0).familyName); > -if IsFontNameDefault(FName) then > +// > +// There's a differnet issue with not using systemFont. > +// NSComboBox, if assigned a manually created font have an odd > ascending-offset > +// (easily seen in Xcode interface builder as well). systemFonts() > +// don't have such issue at all. see bug 33626 > +// the fix below (detecting "default" font and use systemFont()) is a > potential > +// regression for bug 30300. > +// > +// There might font properties (i.e. Transform Matrix) to adjust the > position of > +// the font. But at this time, it's safer to use systemFont() method > +IsDefault := IsFontNameDefault(FName); > +if not IsDefault then > begin >FTmpFont := > NSFont.fontWithName_size(NSFont.systemFontOfSize(0).fontDescriptor.postscriptName, > 0); >FName := NSStringToString(FTmpFont.familyName); > @@ -594,14 +606,14 @@ >include(FStyle, cfs_StrikeOut); > > // If this is not a "systemFont" Create the font ourselves > -FontName := NSStringUTF8(FName); > -Attributes := NSDictionary.dictionaryWithObjectsAndKeys( > - FontName, NSFontFamilyAttribute, > - NSNumber.numberWithFloat(FSize), NSFontSizeAttribute, > - nil); > -FontName.release; > -Descriptor := NSFontDescriptor.fontDescriptorWithFontAttribut > es(Attributes); > -FFont := NSFont.fontWithDescriptor_textTransform(Descriptor, nil); > +if IsDefault then > +begin > + FFont := NSFont.systemFontOfSize( FSize ); > +end else begin > + FontName := NSStringUTF8(FName); > + FFont := NSFont.fontWithName_size(FontName, FSize); > + FontName.release; > +end; > > if FFont = nil then > begin > @@ -620,7 +632,6 @@ > exit; >end; > end; > - > // we could use NSFontTraitsAttribute to request the desired font > style (Bold/Italic) > // but in this case we may get NIL as result. This way is safer. > if cfs_Italic in Style then > -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] 64 bit Cocoa package (Mac)
On Sunday, June 24, 2018, Ryan Joseph via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Is the IDE broken for the Cocoa widget set? > I prefer the word “incomplete” for Cocoa widget. Are you using trunk for Lazarus, or an earlier release? If an earlier release then it’s expected. If trunk then a screenshot would worth a thousand words. Thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] 64 bit Cocoa package (Mac)
On Sun, Jun 24, 2018 at 12:49 AM, Ryan Joseph via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > 1) by setting the Tools > Options compiler path to ppc386 I can rebuild > but I get symbol not found error because the framework I’m linking is 64 > bit only. > 1) If I set the compiler to ppcx64 I get the "Identifier not found > “ATSUFindFontFromName”” error and never get to the building of the actual > package. > > How can I get out of this loop? Apparently lazarus needs to compile the > package and link everything but the IDE also demands I only build with the > i386 compiler. > It's not IDE that demands the compiler to be i386, but the widgetset (Carbon). You need to specify Lazarus to build for Cocoa instead. In this case you should be able to install the package into IDE. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] wikirevenge - wikicare
On Thu, May 3, 2018 at 3:55 PM, Ondrej Pokorny via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > It was created by user Mai who has made more controversial modifications. > See e.g. Bart's note: > > http://wiki.freepascal.org/index.php?title=User_talk:Mai&; > diff=prev&oldid=113125 > > The same time period - end of October 2017. I'd say that the account should be banned. However since the behavior hasn't repeated itself since, it's a bit too late to take any actions. Besides some of the corrections (on other pages) were valid ones. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] wikirevenge - wikicare
Hello, With the recent incident between Maciej Izak and Michael Van Canneyt as well as a forum thread started regarding mORMot (Maciej is working on/with the framework): http://forum.lazarus.freepascal.org/index.php/topic,41138.0.html I couldn't help but to search mentioning of mORMot on the wiki.freepascal.org. To the great surprise the page is there, but was populated with not a nice words towards the authors of the framework. I'd think that "wiki.freepascal.org" is a technical wiki. Personal opinions are not really welcomed there. For example: "this is a great component" should be replaced with "this is a component, with following features: ..." Needless to say, personal opinions regarding other people is even less appropriate (there are many sites out there online for that). At least, there's "discussion" tab available. Keep in mind. Even if you don't like someone or something personally. It doesn't mean that the code they produce or decisions they make are bad. For the wiki admins, please delete the category: http://wiki.freepascal.org/index.php?title=Category:bs it's pretty useless, at the moment. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
On Wed, May 2, 2018 at 9:09 AM, Michael Ring via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > As it is a dead key you first press '^' on the keyboard and then space. > other example: á is created by first pressing '´' and then 'a' > Do you know, if it's required to have German layout to be installed in the system. IIRC (away from mac right now), "^" is entered by pressing Shift+6 on Mac (ansi keyboard with US keys layout) ...and it works. What I'm thinking is that you're trying to enter the character in SynEdit. and it might be that Cocoa doesn't report a certain key combinations properly. I presume you didn't have this issue in Carbon, thus it's neither SynEdit bug nor macOS specific behavior, but rather LCLCocoa issue. That's why I need to know keys combination in order to track the problem on my end. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Cannot enter '^' in Lazarus trunk build macos/cocoa/x86_64
What’s the keys combination to enter ‘^’? Thanks, Dmitry On Wednesday, May 2, 2018, Michael Ring via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > I yesterday tried again after a long time to build Lazarus with Cocoa on > my Mac, Lazarus is now perfectly useable for my needs and as a bonus it > seems a little faster than the Carbon version. > > Great work! > > > The only issue I ran in is that I cannot enter '^' from my german > keyboard and, as a fact, also other charaters composed with deadkeys > (accented keys) like á also do not work. > > > Any ideas on how to fix that? > > > Michael > > > > -- > ___ > 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] Google vs Oracle case - does it affect LCL ?
On Sun, Apr 15, 2018 at 1:24 PM, Michael Van Canneyt via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Take a routine that converts an integer to a string: Why would you > force someone to change what is an obvious name, simply because someone > else already used it ? > I don't think that API is reviewed on per routine basis. API is reviewed as a whole. Also, in 2010 the first trial in US (if jurisdiction matters) court decision was that APIs cannot be copyrighted. So later the case was changed from a copyright violation to unfair use. That's actually contained in the court ruling as well: ( https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.#Appeals_Court_and_finding_of_non-fair-use ) "Instead, the Court found that Google's purpose had been to enhance its nascent Android platform's attractiveness to existing developers, who were often familiar with Java, and to avoid the "drudgery" of rewriting the code (which they could have done) needed to implement the 170 lines of API detail which were indeed required." In general, they're not trying to impose a copyright on each function declaration owned by Oracle. Instead, they're claiming that Google made an unfair use of Oracle's (Sun) work. The unfairness is driven by Google competing with the Oracle with its Android system. If Microsoft will try to come up with its own "windows emulator" for Linux, then they might run into issues with Wine (but Wine would likely win, because they were there first, providing binary compatibility) thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Google vs Oracle case - does it affect LCL ?
On Sunday, April 15, 2018, Michael Van Canneyt via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Of course not. Copyright is theft. Ideas should always be free. API is an implementation of an idea, and it’s up to the author to define license of use. Thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Google vs Oracle case - does it affect LCL ?
On Sun, Apr 15, 2018 at 4:42 AM, Adrian Veith via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > there is an article on phoronix > https://www.phoronix.com/scan.php?page=news_item&px=Oracle- > vs-Google-Wine-API, > which shows that the Google vs Oracle case is concerning Wine developers > because Wine mimics the Windows-API with the function names and > parameters. Under this light the LCL might also be affected because it > mimics the VCL to a large degree - and many fcl libraries mimic > corresponding Delphi libraries. What do you think ? > Reading the wikipedia article (referenced from the article above): "The Court found that as a matter of law, Google's use of Java could not have fallen within fair use,..." ..."It was not transformative in the sense of a new platform either, since other Java smartphones predated Android" In case if Wine, this is actually the case. Because no Windows API existed on Linux platforms, except for Wine. It's also the case for FPC and LCL. I guess the bigger complaint is about: "It was not within any example of transformation, nor intended to permit third party interoperability, since Google had made no substantial efforts to use them for the purpose of third party interoperability. (In fact it found that Google had tried to prevent interoperability with other Java and had previously been refused a license by Sun for that reason)" Btw, the same wikipedia article references POSIX interface. That's actually an example of copyrighted API. In my opinion, having API copyrighted makes sense. It's similar copyrighting hardware interfaces such as USB, COM and HDMI ports. (there was quite a fight around those in the past) A well written API helps dramatically, while poorly written API requires a lot of work with every new version of API released (compare OpenGL vs DirectX) At the same time both POSIX and OpenGL were created as "API" (interface) standards. I'm not sure with WindowsAPI or Delphi were intended as as such. They are more platform specific interfaces (rather than cross-platform) Borland couldn't reuse VCL with Kylix, instead they came up with CLX instead. Where Lazarus with sweat-and-blood keeps up with LCL. Naturally, interfaces between FPC/Lazarus and Delphi are already quite far from one another. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Lazarus 1.8.0: Carbonproc cannot be compiled on El Capitan
On Fri, Jan 19, 2018 at 3:01 PM, Haruo Toda via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Any work-arounds? > > > You're compiling for x86_64 (this is a default selection for macOS for a newer FPC version) you need to specify i386 explicitly thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] new patch- Cocoa- SetScrollInfo funcs
On Sat, Dec 30, 2017 at 12:52 PM, AlexeyT via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > fpc usually gives it (for my code, when i use "var" params). > You should see the warning with source file name and line number when you recompile Cocoa LCL. Can you please provide what the file name and line number is? thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] new patch- Cocoa- SetScrollInfo funcs
On Sat, Dec 30, 2017 at 12:33 PM, AlexeyT via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > +procedure NSScrollerGetScrollInfo(docSz, pageSz: CGFloat; rl: > NSSCroller; Var ScrollInfo: TScrollInfo); > > Pls use "out" instead of "var", because with "var" fpc gives warnings about > not inited parameter > > reasonable! What line gives the warning? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Who is using Object Pascal in production?
Am using FreePascal to create convenience utilities for a web-server applications. (Due to the limitations of the server technology) (here's an example of such utility: https://github.com/skalogryz/docusign though there are more, but the code is not public) Last year delivered an iOS game. Pure freepascal. Didn't have enough power/time/will to finish and release Android version though. However, for game development, the technology doesn't matter, marketing does. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TFilenameedit onchange osx
On Wed, Aug 23, 2017 at 4:24 AM, Denis Kozlov via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > FYI, there are few related bug reports about OnChange not firing correctly > on Mac OS: > https://bugs.freepascal.org/view.php?id=24009 (year 2013) > https://bugs.freepascal.org/view.php?id=30167 (year 2016) > This is a common Carbon behavior (and Cocoa as well). Carbon "change" event is only triggered whenever an actual user input occurred. LCL OnChange event is triggered for both an actual user input or a programmatic change. Naturally, WSCarbon needs to updated to trigger LCL OnChange event whenever a programmatic change occurs. To be honest, it's surprising to see these issues again (a regression?) since they've been worked on back in 2009-2010. I might be wrong though, since similar problem might have been reported for TMemo, TComboBox (rather than TEdit) thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] pmXor pen mode on Mac
On Thu, Jul 20, 2017 at 9:28 AM, Alexey via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Dmitry, i searched for pmXor and i see it's not implemented on Mac too? > No, it's not implemented for sure for either Cocoa or Carbon. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] pmNotXor on Carbon
2017-07-19 12:10 GMT-04:00 Alexey via Lazarus : > Dmitry, can you see, pls, how to add the same on Cocoa WS. Maybe easy... Done. r55543 Same approach as carbon. I'd call it "good enough". -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] pmNotXor on Carbon
2017-07-19 12:10 GMT-04:00 Alexey via Lazarus : > Dmitry, can you see, pls, how to add the same on Cocoa WS. Maybe easy... Should be similar. I'll take a look later today. Are testing it with (cocoa) Lazarus itself? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE-SynEdit Caret Color
Alexey, Martin, thank you for pointing to the right direction. it's now fixed for carbon. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE-SynEdit Caret Color
On Tue, Jul 18, 2017 at 12:33 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > On Tue, Jul 18, 2017 at 11:38 AM, Alexey via Lazarus < > lazarus@lists.lazarus-ide.org> wrote: > >> Caret should paint via pmNotXor (or pmXor) pen mode. MacOS WS bug - it >> paints it always black. Win32 should paint Ok. > > > A stand-alone project with SynEdit, draws the caret as expected (with > internal colors) > However, IDE caret always appears to be black. Drawing of the caret > doesn't seem to be happening via WS. > > So I'm wondering is multi-caret / Internal synedit drawing is enabled at > all time. > Just like Martin said - the internal painter is used. The code of the internal caret painter sets pmNotXor mode when drawing lines. The value seems to be ignored by WS -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE-SynEdit Caret Color
On Tue, Jul 18, 2017 at 12:33 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > A stand-alone project with SynEdit, draws the caret as expected (with > internal colors) > * (with inverted colors) -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] IDE-SynEdit Caret Color
On Tue, Jul 18, 2017 at 11:38 AM, Alexey via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Caret should paint via pmNotXor (or pmXor) pen mode. MacOS WS bug - it > paints it always black. Win32 should paint Ok. A stand-alone project with SynEdit, draws the caret as expected (with internal colors) However, IDE caret always appears to be black. Drawing of the caret doesn't seem to be happening via WS. So I'm wondering is multi-caret / Internal synedit drawing is enabled at all time. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] IDE-SynEdit Caret Color
Hello Is there an option to control caret color of IDE editor? I typically use classic color scheme, that means blue background with yellow text. However, the OS caret still draws the caret in black. On SynEdit internals, there's a way to use an internal caret painter TSynEditScreenCaret.Create(.., TSynEditScreenCaretPainterInternal) and that provides a precise control over how caret looks. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Which HTML render component better?
Chromium embedded would be the best HTML rendering option as of today. http://wiki.freepascal.org/fpCEF3 It would actually put a heavy toll on a size of any project, but it takes care of it all (html, js... whatever). -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Vulkan Library for FreePascal/Lazarus
On Thu, Apr 13, 2017 at 12:32 AM, James.mcjohnson via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > The project is located at https://github.com/james-mcjohnson/ > VulkanLibraryForFreePascal and I would appreciate any constructive > feedback. > Added to the wiki http://wiki.freepascal.org/Vulkan#Headers thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Support for lldb ?
On Sat, Mar 18, 2017 at 9:20 AM, Michael Van Canneyt via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Is support for lldb for Lazarus planned ? Technically, it should not be a problem. lldb allows to debug any application, it's not llvm specific at all. I'm actually using lldb a little bit, for iphone-laz extension. Nothing fancy - it launches a simulator and then hijacks its stdout (by redirecting it from the simulator app) to be shown on the IDE side. It works just fine for fpc compiled apps. Back in a days (pre lldb era), I tried to adapt Apple's gdb for Lazarus needs, but couldn't figure out Lazarus debugger apis. (it was too gnu gdb oriented). It has changed since, but I didn't touch it. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TruBrain user activation
It should be blocked asap, since now its receiving mailing list and would steal everyone's email addresses. thanks, Dmitry On Fri, Mar 3, 2017 at 1:22 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > Spammers have to be blocked. > > thanks, > Dmitry > -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TruBrain user activation
Spammers have to be blocked. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Thu, Nov 3, 2016 at 4:17 PM, silvioprog via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Nothing special, just because some commented code there hehe... xD But > what is the main purpose about SetTextUIStyle, it retrieves only links, or > links and formatted texts? :-) > > Currently, it sets/gets links only (formatted texts go with FontParams and GetTextAttributes). If more features are to be added, it might easier to extend TTextUIParam structure, rather than introducing more methods to WSclass. Something similar that happened to TFontParams. The structure didn't have Background colors or script positions (for ascended/descended texts) thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Thu, Nov 3, 2016 at 3:36 PM, silvioprog via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> There's ALinkRef parameter, that serves this particular purpose.
>>
> Naturally, LinkRef should end up in TLinkMouseInfo .
>>
>
> Perfect.
>
Now, I take that back.
"ref" information might need to go to some other, rather than
TLinkMouseInfo.
Instead, TLinkMouseInfo should contain information about the cursor (x,y,
shift state, etc)
An extra parameter could be added that would contain LinkInformation
I have a question regarding SetTextUIStyle for WinVCL,
>
Why WinVCL? :)
> what about to change it to?
>
> txt := GetTextUtf8(RichEditWnd, true);
> st.codepage:=CP_UTF8;
> st.flags:=ST_SELECTION;
> linkrtf:=Concat('{\rtf1{\field{\*\fldinst{ HYPERLINK
> "',ui.linkref,'"}}{\fldrslt{ ',txt,' ');
> SendMessage(RichEditWnd, EM_SETTEXTEX, WPARAM(@st), LParam(@linkrtf[1]));
>
That's fine. You just need to make sure that parameters are RTF escaped.
Also, newer versions of RichEdit do provide API for Link management without
need of going into raw RTF.
But that's why TRichEditManager class is there (even through there's only
one implementation available)
thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Thu, Nov 3, 2016 at 2:52 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > > But I'd like to note, that "Links", are yet "under construction" area. For > a few reasons: > > one more thing: * custom RTF reader/writer must also be updated to recognize the link and use the proper API to generate one. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Thu, Nov 3, 2016 at 5:18 AM, Torsten Bonde Christiansen via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > If it all possible, can the part that generates the RichTextFormat be > moved from the component into a seperate unit. This will make it possible > to include RTF generators into eg. console programs. > Yes, it is possible thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Wed, Nov 2, 2016 at 10:25 PM, silvioprog via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > I had some ideas, and I can send small patches showing them. For example, > what do you think about adding the GetLink() method in the TCustomRichMemo > class and the href:string attribute in the TLinkMouseInfo record? > You might want to refer to SetLink method. There's ALinkRef parameter, that serves this particular purpose. Naturally, LinkRef should end up in TLinkMouseInfo . But I'd like to note, that "Links", are yet "under construction" area. For a few reasons: * old win32 rich edit (for WindoesXP, doesn't have an api to read "href" data. However, a raw access to RTF could be used to extract it... as well as to store it) * setting up a link >>might<< (not critical at themoment) require one more piece of information: Hint text (the text that's shown in the tooltip window) However, if you implement Gtk side and add linkref or href to TLinkMouseInfo, the patch will be accepted. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Wed, Nov 2, 2016 at 7:25 PM, silvioprog via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Done: http://bugs.freepascal.org/view.php?id=30852 . > Yep, totally fine. Should accept it tonight. Thank you. ps. this component should be installed as default in Lazarus IDE. ;-) > It's not my call. Including a component into an IDE is a big administrative issue. The main question is - how - the component is included: as a part of LCL (default components set) or as 3d-party component. If the component to become LCL-default component, then the whole work of maintaining it goes to respective widgetset maintainers. If the component to go as a 3d party component, then it needs some sort of versioning in place (and this is not the case for richmemo). So it would be clear which version (revision) of the component goes with the next Lazarus release. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Question about TRichMemo
On Tue, Nov 1, 2016 at 10:50 PM, silvioprog via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > Anyway, I'm going to send some patches to improve this component ... > Thank you! Looking forward! Pure Delphi-compatibility patches are likely to be rejected. (unless they're implemented in the form of helpers) Keeping in mind cross-platform compatibility is greatly appreciated (thus Windows only features are likely to be rejected as well... or could be added in a form of functions/helpers, rather than a part of TCustomRichMemo interface) thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Scrollbars on form ?
Did you set AutoScroll to true? thanks, dmitry On Sat, Sep 24, 2016 at 2:09 PM, Michael Van Canneyt via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > > Hi, > > How is one supposed to get the scrollbars on a form to work ? > I have a form, with a custom control on it which is bigger than the form. > I would expect the scrollbars to appear if AutoSize is false, and both > scrollbars have visible set to true. > > However, no matter what the combinations of properties I set, the > scrollbars > on the form do not appear. > > Is there some trick to this ? > > Michael. > -- > ___ > Lazarus mailing list > Lazarus@lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
