Re: [Lazarus] Request for merge to 2.0

[Martok via lazarus]

> There was an attempt to merge it to 2.0.10 but conflicts prevented it. I did 
> not
> study deeply how to solve them.
> There will be no more patch releases for 2.0.x series. The next release will 
> be 2.2.

Ah, right, well that also solves the issue :-)

> For now I would recommend Lazarus trunk for you. It works very well now.

Personally I've been using nothing but trunk of both Lazarus and FPC since some
time during the FPC 2.7 cycle... other, more conservative people have asked me
about this bug and it seemed like a good thing to backport.


Also, sorry about the double message. My mail server gave me an error after
sending the first, but obviously that got through just fine.


Regards,

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

[Lazarus] Request for merge to 2.0

[Martok via lazarus]

Dear maintainers,

may I ask to merge rev 62042 into fixes_2_0 for the next patch release?

This change from 2019 fixed building Lazarus with sparta_DockedFormEditor (see
#34899), which is still broken in 2.0.10.

Juha mentioned in #37968 that the sparta_Generics package will go away once 3.2
is the minimum requirement, but r62042 solves the issue for new FPC while
keeping compat with old. And since the official Windows installers come bundled
with FPC 3.2, the bug occurs with the current distribution.


Thanks,

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

[Lazarus] Request for merge to 2.0

[Martok via lazarus]

Dear maintainers,

may I ask to merge rev 62042 into fixes_2_0 for the next patch release?

This change from 2019 fixed building Lazarus with sparta_DockedFormEditor (see
#34899), which is still broken in 2.0.10.

Juha mentioned in #37968 that the sparta_Generics package will go away once 3.2
is the minimum requirement, but r62042 solves the issue for new FPC while
keeping compat with old. And since the official Windows installers come bundled
with FPC 3.2, the bug occurs with the current distribution.


Thanks,

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

Re: [Lazarus] Universal FontDialog for LCL

[Martok via lazarus]

> The first issue I found is that the setup dialog for fppkg doesn't look  
> for a fppkg executable, it expects the install directory where is fpc  
> supposed to be installed, I guess in order to use that for locating the  
> right fppkg executable. I expect this to work as is only on released  
> Lazarus because it tries to find the fpc executable by using the PATH  
> environment dirs. This means that it doesn't matter what you choose in the  
> setup Lazarus dialog as your desired compiler. I think this is the first  
> thing that needs fixing. The rest should come after that.

Actually, an idea.

fppkg (the standalone) has a -C option, and one could have fpcmkcfg -3 and -4 to
create a correct config for a compiler that is not on the PATH and place it next
to fpc.cfg.

If the Lazarus packager fppkghelper would offer the same and try loading
'$(Path($(CompPath(IDE)))\fppkg.cfg', I think most problems would be solved.
CompPath(IDE) isn't entirely correct either, but it would be less wrong than the
current order...

-- 
Regards,
Martok


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

Re: [Lazarus] How to configure Fppkg in IDE startup dialog with FPC 3.2 ?

[Martok via lazarus]

Am 02.03.2019 um 16:04 schrieb Joost van der Sluis via lazarus:
> If you want to know it for sure, you have to do what the error-message 
> is telling you: re-install fpc. Using an official fpc-release, 
> offcourse. (https://www.freepascal.org/download.html)

So, I typed and deleted about 5 different replies to this message. In the
interest of not taking up Tomas' (or whoever acts as moderator on this list)
time, you'll get this one:

I wish you all the best, and have fun explaining your concept to whoever ends up
building the Lazarus >2.2 + FPC 3.2 release bundles. Maybe you'll understand
then what we've been trying to tell you for months now.
Good luck.

-- 
Regards,
Martok


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

Re: [Lazarus] How to configure Fppkg in IDE startup dialog with FPC 3.2 ?

[Martok via lazarus]

Am 02.03.2019 um 13:32 schrieb Joost van der Sluis via lazarus:
> Then something is wrong with fpcupdeluxe.

If FPC, Lazarus, fpmake all find the correct paths, but fppkg does not, then
this is clearly the installer's fault.
Flawless logic.

-- 
Regards,
Martok

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

[Lazarus] fppkg - autodetect on Windows

[Martok via lazarus]

Hi,

I've just rebuilt Lazarus and FPC, and noticed that fppkg is a lot less
intrusive again, which is good.

In the setup dialog, which directory is one supposed to specify (see attached
screenshot)? I have modified the installer so that the fpmkinst-directory is
also deployed, but nothing I enter seems to enable the "Create Config" button.

I tried:
$(LazarusDir)\fpc\$(FPCVer) (this is what intuitively makes sense)
$(LazarusDir)\fpc\  (this is what the text asks for)
$(LazarusDir)\fpc\$(FPCVer)\bin


At least it is safe to ignore again (without it creating a faulty config) and
Lazbuild also works, so automated builds work again.

-- 
Regards,
Martok
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus with fpc 3.2 [was Re: [fpc-devel] Suspicion about TThread.Synchronize]

[Martok via lazarus]

Am 13.02.2019 um 14:17 schrieb Werner Pamler via lazarus:
> No, you must use the VirtualTreeViews which comes with Lazarus (folder 
> components/virtualtreeview).
Sorry to barge in here, but is this version actively maintained again? I
distinctly remember from 2016 that it was extremely outdated and did not
incorporate upstream development at all.

Too many forks...

-- 
Regards,
Martok


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

Re: [Lazarus] lazbuild question

[Martok via lazarus]

Am 01.02.2019 um 21:48 schrieb Joost van der Sluis via lazarus:
> chm Is not a Lazarus but a fpc package. Seems that your fppkg configuration 
> is currupt. > My guess is that it works in Lazarus itself because you haven't 
> compiled
Lazbuild in a while.

Ryan,

can you check what versions of FPC you have installed (and where), which of
those is found from the PATH by `which fpc`, and which of those is configured
for Lazarus?

Fppkg does not play well with user-local installations and wholly ignores the
CompPath config of Lazarus, so it may look for an old path that is no longer
present. There have been a few changes to that recently, so if your lazbuild is
of a different version, it may follow another logic than lazarus.

-- 
Regards,
Martok

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

Re: [Lazarus] IDE fppkg error message

[Martok via lazarus]

Am 24.01.2019 um 13:42 schrieb AlexeyT via lazarus:
> After changing FPC from 3.0.4 to 3.3.1 i see this error on IDE start.
See 
Short version:

Lazarus now has a hard dependency on properly (and globally!) configured fppkg,
which requires fpc in your PATH.

Upside: Lazarus supposedly needs it for something to do with fpmake
dependencies, but it only really affects looking up paths of packages installed
via fppkg.
Downside: completely breaks the default Windows setup as well as any
self-contained installations (on any OS).

> b) how to avoid it?
Not currently fixable by a user.

However, as this only occurs when you have never run the fppkg client before,
you also cannot have any fppkg-managed packages, meaning the message is
perfectly safe to ignore. See attached patch, which restores the old logic.
Compiling *will* work even if fppkg is not configured (as it always has), as fpc
correctly uses fpc.cfg to find the package paths.


-- 
Regards,
Martok

Index: packager/fppkghelper.pas
===
--- packager/fppkghelper.pas(revision 60047)
+++ packager/fppkghelper.pas(working copy)
@@ -71,8 +71,8 @@
   FFPpkg := FPpkg;
   FPpkg := nil;
 except
-  on E: Exception do
-IDEMessageDialog(lisFppkgInitializeFailed, 
Format(lisFppkgInitializeFailed, [E.Message]), mtWarning, [mbOK]);
+  //on E: Exception do
+  //  IDEMessageDialog(lisFppkgInitializeFailed, 
Format(lisFppkgInitializeFailed, [E.Message]), mtWarning, [mbOK]);
 end;
   finally
 FPpkg.Free;
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] inherited in autocode

[Martok via lazarus]

> This is probably to protect from calls to virtual methods?

Sorry, meant to say "protect from calls to abstract methods", specifically from
autogenerated code.


-- 
Regards,
Martok


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

Re: [Lazarus] inherited in autocode

[Martok via lazarus]

Am 13.01.2019 um 01:36 schrieb Martin Frb via lazarus:
> Well, I was told it was the same 
> https://bugs.freepascal.org/view.php?id=33862

Depends on how one reads the Emba Developer's comment.

""" In such case, a call to an inherited method may occur if it exists or not if
it doesn't. Such a reference is limited to methods with the same name and
parameter list *in the parent class* """ (emph. mine)

I would read that so that it only looks in *the* parent class, not "any ancestor
class". If it finds nothing, it indeed generates no code and no error.

As observed, if it finds a matching name with wrong parameter list, an error is
raised.


Fun Fact: if a matching name and parameter list exists and is virtual abstract,
no code will be generated either. This is probably to protect from calls to
virtual methods?

-- 
Regards,
Martok


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

Re: [Lazarus] inherited in autocode

[Martok via lazarus]

Am 12.01.2019 um 23:45 schrieb Martin Frb via lazarus:
>>  inherited;   // calls TObject.Create!
> because TObject has a matching constructor.

Indeed. But in Delphi, "inherited without function name" stops looking after one
mismatched argument list (just like override would), so it never gets to 
TObject.

FPC keeps going up the ancestor chain.

-- 
Regards,
Martok

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

Re: [Lazarus] inherited in autocode

[Martok via lazarus]

Am 12.01.2019 um 22:28 schrieb Martin Frb via lazarus:
> Same for constructors, if the parent constructor changes its argument 
> list, it will no longer be called.
It does generate code, but it calls *any* inherited constructor that matches the
signature:

  type
TA = class
  constructor Create(extra:Boolean);
end;
TB = class(TA)
  constructor Create;
end;

  constructor TA.Create(extra: Boolean);
  begin
inherited Create;
WriteLn('TA.Create');
  end;
  constructor TB.Create;
  begin
inherited;   // calls TObject.Create!
WriteLn('TB.Create');
  end;


> That is indented behaviour and apparently Delphi compatible.
Delphi 2007 fails compilation with "Incompatible Types" when no compatible
method of the same name exists, which makes sense.


-- 
Regards,
Martok

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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 03.01.2019 um 00:31 schrieb Joost van der Sluis via lazarus:
> Should be fixed. In FPC (added the check if the compiler exists) and in 
> Lazarus (do not choke on it when an exception occurs)

I just found out something else -- the exception also breaks Lazbuild, which,
since it doesn't have a GUI, can't do anything about it (by the way - the
IDEMessageDialog title is using the wrong string constant).

> Error: (lazbuild) An error occured during the initialization of Fppkg: %s.
> Check your Fppkg configuration and restart Lazarus to be able to use Fppkg's 
> functionality.
> An error occured during the initialization of Fppkg: Could not find a fpc 
> executable in the PATH.
> Check your Fppkg configuration and restart Lazarus to be able to use Fppkg's 
> functionality.
> LazBuild ist nicht interaktiv, es wird abgebrochen.

Lazbuild doesn't even have theoretical facilities to be a fppkg frontend (that
is, install the ide package), so that makes no sense at all. It's completely
unneeded for building - fpc finds its own fpc.cfg, therefore it would find the
units to use.


Oh, and unrelated: "fppkg list" just prints an error 404. Wherever that comes 
from.

-- 
Regards,
Martok


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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 06.01.2019 um 21:11 schrieb Joost van der Sluis via lazarus:
> That's more a coincidence. Because all executables are installed into 
> the same location.
For some values of "coincidence"...

On Windows, fpc lives in the Lazarus dir:
Lazarus\fpc\$FPCVer\bin\$HostCPU-$HostOS\
  - fpc.exe
  - fpmkcfg.exe
  - fppkg.exe
  - ppc whose $TargetCPU-$TargetOS is $HostCPU-$HostOS
  - possibly crosscompilers and their binutils
Lazarus\fpc\$FPCVer\units\$TargetCPU-$TargetOS\
  - .o and .ppu for any possible target

One may have other host compilers, although the only useful combination is using
native win64 and native win32 compilers in parallel. Both will have their own
non-cross-binutils etc. Both paths will have their own fpc.exe -- it's basically
having done "make install" with different prefixes.

> That won't work here, because pkgoptions is part of the fppkg-library. 
> In this particular case it will retrieve the path of the Lazarus-executable.
Huh? Then can't it just get the Lazarus configured compiler path?
I thought that part was in the fppkg binary.

> That sounds strange, it should use the normal configuration that is used 
> by fpc to allow cross-platform setups? But I'm not sure exactly how the 
> configuration files look like if they are generated this way on Windows.
Ah, sorry, I was unclear.
If it worked, fppkg would put its configuration in %appdata%\FreePascal\fppkg\,
whereas Lazarus would be in %appdata%\lazarus\. On Windows, the FPC installation
"belongs to" the Lazarus installation and will be removed/replaced on updates.
There may also be more than one of these. I would expect Lazarus to tell fppkg
what paths to use when it needs it to rebuild something, because only the
running Lazarus instance can know what setup it was told to work with.

-- 
Regards,
Martok

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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 03.01.2019 um 22:27 schrieb Joost van der Sluis via lazarus:
> I actually don't know how to create the configuration files on Windows. 
So, I checked the source, and it seems you actually do ;-)
The Lazarus side generates a config if none is found (in a weird place, but that
is just GetAppConfigFile being what it is). The problem is in fppkg on the the
compiler side. My preferred fix would be also checking the fppkg exe path,
because that's where "make install" puts it on windows, i.e.:

packages\fppkg\src\pkgoptions.pp:1119:
FCompiler:=ExeSearch('fpc'+ExeExt,ExtractFilePath(ParamStr(0)) +
PathSeparator + GetEnvironmentVariable('PATH'));

The shared config file is still wrong if more than one full platform is
installed (not usually done on unices, but that's how the Lazarus Windows
installer sets things up -- see also --primary-config-path), but that's a
different issue.

-- 
Regards,
Martok

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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 03.01.2019 um 22:27 schrieb Joost van der Sluis via lazarus:
> I actually don't know how to create the configuration files on Windows. 
> (Except from letting Lazarus create them automatically based on the 
> path, as described above. Or create them manually, or use fpcmkcfg... 
> well... damn..)
Calling fpcmkcfg for all provided compilers is part of the procedure for my
snapshots anyway - if there is a way to generate one for fppkg as well, I'll be
happy to include that.

> Or, maybe, just wait for a better solution.
Will do.
Non-actionable messages are just always bugging me ;-)

-- 
Regards,
Martok

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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 03.01.2019 um 11:00 schrieb Joost van der Sluis via lazarus:
> The same holds if you remove gdb, make or the source-files of fpc's 
> packages. While in principle Lazarus could be used without those.

Okay, now I feel even more confused than before...

I didn't remove anything?

I build clean Lazarus (not even bigide) + FPC from trunk using fpclazup, start
it, and now receive a warning that wasn't there on last week's build. What steps
do I need to take to fix this? I will most definitely *not* put fpc in my
%PATH%, which the dialog wants me to do. Can't it just use the $(CompPath) 
macro?

> Question is where it did go wrong. You probably altered the 
> configuration yourself, and thought that you did that properly, because 
> no-one ever noticed you that there was a mistake somewhere. Lazarus now 
> notifies you about the mistake.
Nope. Even tested with a new clean Lazarus profile dir (so there is absolutely
nothing left from previous versions), same result.


Also, you write about fpmake but the problem is fppkg?


> like compiling LCL-based applications on the command-line
lazbuild?


Seriously confused regards,
Martok

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

Re: [Lazarus] Can't start lazarus trunk

[Martok via lazarus]

Am 03.01.2019 um 00:31 schrieb Joost van der Sluis via lazarus:
> Should be fixed. In FPC (added the check if the compiler exists) and in 
> Lazarus (do not choke on it when an exception occurs)

This may be a stupid question, but why do I now have to click through a message
"An error occured during the initialization of Fppkg: Could not find a fpc
executable in the PATH.
Check your Fppkg configuration and restart Lazarus to be able to use Fppkg's
functionality." ever time I start Lazarus?

I'm not aware of ever installing/enabling/whatever-one-does any sort of package
manager, neither fppkg nor OPM...

-- 
Regards,
Martok

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

Re: [Lazarus] With new Win32 manifest LongPathAware I cannot make long filename

[Martok via lazarus]

Am 23.11.2018 um 15:24 schrieb AlexeyT via lazarus:
> This app cannot make 2nd folder (it can make 1st) and make file. Error 
> on file saving. why? new manifest option is used. Win10.

Does the same code work if you use the LongPathsEnabled registry setting?

If so, there may be something off with the manifest...

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] what can we do to get a better debugger

[Martok via lazarus]

Am 20.11.2018 um 11:37 schrieb Dennis via lazarus:
> FPC and Lazarus are great but the GDB is inadequate.
> Many times in my development, GDB failed or crashed, especially when I am
> debugging multi thread programs.
> 
> Shall we start a fund raising event to raise fund for a new and better 
> debugger
> for FPC + Lazarus? (provided there are talents out there who would do 
> implement it).

So much this. GDB needs to die in a fire.

(nb: make sure to enable "Reset debugger after every run". That at least works
around the absurd amount of memory leaks, and helps with lost breakpoints.)

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Cross-compile Linux -> Win fails in win32lclintf.inc

[Martok via Lazarus]

SameStr was introduced in FPC 3.0.2.

I'm pretty sure Lazarus trunk requires 3.0.4 anyway? Where was that documented,
again?

-- 
Regards,
Martok


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

Re: [Lazarus] Package/New Package broken

[Martok via Lazarus]

Am 19.05.2018 um 00:27 schrieb Werner Pamler via Lazarus:
> I cannot confirm the issue either (I am German, too). I do no see the 
> space in the name. Are you sure that you did not enter it yourself?
Happens for me too, no input required. This used to work at some point...

Lazarus-1.9-57954_fpc-3.1.1-39024M

Backtrace:
> #0  0x0040f676 in fpc_raiseexception ()
> #1  0x004899e4 in CLASSES$_$TCOMPONENT_$__$$_SETNAME$ANSISTRING ()
> #2  0x0055f931 in SETNAME (this=0x2f1e68, VALUE=0xb79a07c 
> 'PackageEditor_Neues Package') at include/control.inc:3492
> #3  0x00b247ad in PACKAGEEDITOR$_$TPACKAGEEDITORFORM_$__$$_UPDATEALL$BOOLEAN 
> ()
> #4  0x00b23a70 in 
> PACKAGEEDITOR$_$TPACKAGEEDITORFORM_$__$$_SETLAZPACKAGE$TLAZPACKAGE ()
> #5  0x00b28328 in 
> PACKAGEEDITOR$_$TPACKAGEEDITORS_$__$$_CREATEEDITOR$TLAZPACKAGE$BOOLEAN$$TPACKAGEEDITORFORM
>  ()
> #6  0x0892be18 in ?? ()
> #7  0x007fbee4 in PKGMANAGER$_$TPKGMANAGER_$__$$_DONEWPACKAGE$$TMODALRESULT ()
> #8  0x007f4a48 in 
> PKGMANAGER$_$TPKGMANAGER_$__$$_MAINIDEITMPKGNEWPACKAGECLICK$TOBJECT ()
> #9  0x00732325 in MENUITEMCLICK (this=0xb4d13e0, SENDER=0xb4ce2f8) at 
> menuintf.pas:544
> #10 0x00734df5 in MENUITEMCLICK (this=0xb4d13e0, SENDER=0xb4ce2f8) at 
> menuintf.pas:1705
> #11 0x00585f40 in CLICK (this=0xb4ce2f8) at include/menuitem.inc:83
> #12 0x005865bf in DOCLICKED (this=0xb4ce2f8, MSG=0) at 
> include/menuitem.inc:293
-- 
Regards,
Martok


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

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

> I will mention 1 case in point. Const parameters.
> 
> For years, people mistakenly assumed that Const parameters were 
> be passed by reference if they were "big" (records), a behaviour which
> Delphi exhibited.
People actually believed that? When the documentation explicitly stated that var
parameters are the *only* byrefs, everything else being passed by value (which
technically makes the special case for large objects a bug)? Oh well.

One might argue if code is documentation for EOL products - they can't change
their minds about Turbo Pascal any more. And with the long standing policy of
being source-code compatible all the way back, that should mean something
regarding the same language constructs in current versions. But still, Delphi is
a moving target, and some things have long branched way past the point where one
might aim to be "compatible".

Why do I feel we're both arguing the same side here? ;-)


--Martok

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

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 19.02.2018 um 11:10 schrieb Sven Barth via Lazarus:
> As long as the code does not rely on undocumented behavior, yes. 
And therein lies the issue. Things that worked the same way for >25 years and
are mentioned explicitly in numerous secondary literature are considered
"undocumented". And whatever is the official documentation anyway - the
yellow-{blue,red} books? .hlp? .hxs? Docwiki? And in which translation?

Don't get me wrong: I *get* why the choices that were made needed to be made to
get cross-platform consistency within fpc. I even agree with most of them. I
just think it would be dishonest to pretend they weren't made. That was the
entire point of my earlier post.


Am 19.02.2018 um 13:51 schrieb Michael Van Canneyt via Lazarus:
> Do you have examples where it does not ?
I listed some right below. Mind you, none of them are esoteric corner-cases: the
Interface stuff is any LINQ-alike ever, PixelFormat means Scanline and blit
performance, etc.

>> That's kinda the opposite of what the technical definition of
>> "source-code compatible" means.
> Really? Where did you find this definition ?
Wikipedia. They make it about portability of the function of a program across
platforms (read: compilers).

> And that's all there is to say about it.
Indeed it is. Once one internalizes that there is at best accidental
compatibility, a lot of pain goes away. Just treat fpc as a completely different
language system with some deceptively named syntax modes, and you end up with a
pretty great compiler.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 19.02.2018 um 00:18 schrieb Michael Van Canneyt via Lazarus:
> Why is it obviously not true ? It's obviously not true that it is compatible
> at the binary level. FPC does not produce the same binary code
I'm more talking about the macroscopic perspective. Of course the binary code
may be different, but does it have the same concept of what a specific block of
source "means"?

Or, put differently,
> But source code written for Delphi must compile in FPC.
Should it also do something *similar*?

Just from the things that come up at least twice a year in the time since I
started actively following the lists... tempvar allocation and lifetimes
(especially with respect to interface refcounting), TBitmap Pixelformat & co,
LCL event order, my pet peeve small type memory layout...
I get why most of them are/must be different, it's just that code compiles, but
stops working. That's kinda the opposite of what the technical definition of
"source-code compatible" means.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Form events firing order and count

[Martok via Lazarus]

Am 18.02.2018 um 20:39 schrieb Michael Van Canneyt via Lazarus:
> It's already fixed in SVN :)
FYI:
Line 121 contains a double http://
Line 234 is missing a "y" on "necessar_y_".


Also, while we're apparently in the off-topic section of this thread, a thought:
"""
fpc is designed to be, as much as possible, language and source-level compatible
with ISO pascal, Mac Pascal, Turbo Pascal 7.0 and most (if not all) versions of
Delphi.
"""
I wonder if you shouldn't leave out the words "source-level compatible", since
that is obviously not true. That phrasing implies the same code will do the same
thing (if it compiles), but with the amount of intentional differences between
fpc and "undocumented internals" of Borland's products that keep popping up, it
might be less surprising to people looking to write portable code if the claim
wasn't made in the first place. Same goes for LCL, really.

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Byte-Alignment of TBitmap

[Martok via Lazarus]

Am 01.01.2018 um 20:22 schrieb Marc Weustink via Lazarus:
> Why does than mean that the alignment is wrong? Based on what did you draw 
> that conclusion?
The value of PixelFormat has little relation to the actual pixel format, except
for 1bpp and 32bpp.
For example, a pf8bit bitmap should have 1 Byte per pixel, so the ScanLine is
effectively a PByteArray. This is not the case for LCL-bitmaps...


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

[Lazarus] Byte-Alignment of TBitmap

[Martok via Lazarus]

Hi all,

this showed up in the Discussion around 32876 and 30509:
> LCL Tbitmap supports 1,24 and 32 bit images from what I see.

That is indeed true:
  luma.PixelFormat:= pf8bit;
  luma.SetSize(100, 100);
  // now: luma.RawImage.Description.Depth == 24

That of course means that the alignment for RawImage access (using Scanline) is
wrong, and code ported from Delphi doesn't work at all.

How is one supposed to do this? Or is that a not implemented feature?


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] PackageLinks dialog

[Martok via Lazarus]

> Alexey via Lazarus  wrote:
> 
 - enable option RowSelect  
>>> Why?  
>> Now selection is barely visible with thin frame on 1 cell.
> 
> In my theme the thin frame is the active cell. A selected cell has a
> different background.
Only if the selected cell is not also focused, example:


Why is that a TStringGrid, anyway? Wouldn't the better choice be a TListView  in
report mode? Were there any specific reasons?

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Rendering Issue Emoji for HTML List Items

[Martok via Lazarus]

Am 17.10.2017 um 08:36 schrieb R0b0t1 via Lazarus:
> Thank you for clarifying - I wasn't sure if the OP was also talking
> about an issue with the code editor.
Neither was I - now I know it's not something that can be fixed on LCL/FPC side,
so that's that. Guess there's a reason why browser vendors use third party text
renderers...

It was theoretically possible that this codepoint triggers some sort of corner
case in UTF8 processing (why would it matter if a character is the first or
second in a string?), but it appears everything is fine and windows just does
windows things.

Thank you for clearing that up!

-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

[Lazarus] Rendering Issue Emoji for HTML List Items

[Martok via Lazarus]

Hi all,

when I checked what HTML2TextRenderer uses to translate list items, I found that
since rev 55743 it uses U+26AB MEDIUM BLACK CIRCLE ⚫ and U+26AA MEDIUM WHITE
CIRCLE ⚪. There seems to be some issue with these codepoints when rendering them
to a Canvas on win32 widgetset: they only render correctly in an application
when they are not the first character in a sequence OR the host is Win10, but
never in the Lazarus SynEdit.

The slightly smaller versions U+25CF BLACK CIRCLE ● and U+25CB WHITE CIRCLE ○
work fine.

Example (make sure to save in UTF8, default in Lazarus):
---
procedure TForm1.FormPaint(Sender: TObject);
var
  s: string;
begin
  s:= '●⚫';
  Canvas.TextOut(100,100,s);
  s:= '⚫';
  Canvas.TextOut(100,150,s);
end;
---
The first TextOut produces 2 circles (the first one being smaller), the second a
"missing glyph" box. The second line will also do that in the code editor. It
may work in the application on Win10, but not on older systems.

Could someone please test this on other widgetsets, so I have an idea
whether/what/where to report this?
Thanks!


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

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

Re: [Lazarus] Mousewheel events on TCustomControl

[Martok via Lazarus]

Hi,

> your scrollbars are part of control? I mean, are they created via
>   ShowScrollBar(Handle, SB_HORZ, True);
>   ShowScrollBar(Handle, SB_VERT, True);  ?

No, they are created as TScrollBar controls parented to the control and placed
in the client area. There should be nothing giving the widgetset the impression
that this scrollbar is somehow scrolling the window...


> [I] wrote component ECScheme, it is part of ECControls and I didn't use
> DoMouseWheelxxx methods at all. I use
>   procedure WMHScroll(var Msg: TWMScroll); message WM_HSCROLL;
>   procedure WMVScroll(var Msg: TWMScroll); message WM_VSCROLL;  

The messages are not received at all, no matter the handler. But thanks for the
reminder, if it works I'll need these either way for horizontal scrolling :)

-- 
Martok


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

[Lazarus] Mousewheel events on TCustomControl

[Martok via Lazarus]

Hi all,

I'm having some strange trouble with mouse interaction with a
TCustomControl-derived component. I have only been able to test with the win32
widgetset, and it works on some machines and doesn't work on others.

The component draws its content to its TCanvas, and additionally places some
controls in its client space. Specifically, TScrollBars which the user can use
to scroll segments of the content.

I want to add mouse wheel scrolling in the client area, so I overwrite
DoMouseWheel and put my handling there. This works well on some systems, but for
others (including my main development system), the MouseWheel message is not
delivered to the CustomControl, but instead to what appears to be the first
TScrollbar (not necessarily the focused control). The component never receives 
it.

Do you have an idea what could be happening here, and how I could fix that?
MouseCapture might be an idea, but all examples I've seen don't seem very
reliable at un-capturing. I also want the solution to be stable across other
widgetsets...
-- 
Martok


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

Re: [Lazarus] Debugger constantly crashing.

[Martok via Lazarus]

> This is a bug in gdb, so we can not fix it on our end.
Is this a known bug reported at upstream? Maybe even with patch that they don't
want to apply (again)? If so, do you have a reference?

I've seen similar errors occasionally too, and since I use custom patched gdb
(on Win targets) anyway, that'd be a handy one to add.


--
Martok

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

Re: [Lazarus] Breaking change

[Martok via Lazarus]

Am 23.07.2017 um 22:01 schrieb Sven Barth via Lazarus:
> - aggregates (which is what a TGUID is) are always passed as pointers
> for stdcall functions (basically all functions that are related to COM
> and thus to REFIID) and also the Win64 ABI anyway, so a mere "TIID"
> already behaved correctly for the Windows targets
They weren't always, at least in this particular revision I reported the
original bug against. Ended up having the GUID itself on the stack, not a
reference - but only with const, and only in some functions. No specifier would
have worked too, but I think constref is more descriptive.

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

Re: [Lazarus] Breaking change

[Martok via Lazarus]

>>{ IUnknown }
>>function QueryInterface({$IFDEF
>> FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} IID: TGUID; out Obj): Hresult;
>> virtual; {$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
> 
> That is a historical monstrosity :)
I a gree we can do away with the IFDEFS and just use constref.

>> But I see already it has been translated differently in every unit (mostly
>> because MS made it uniform only after the headers were translated), so might 
>> as
>> well use the new one to keep things interesting. Carry on.
> 
> I agree the matter is a bit dubious :/
I think it's really not. We can transparently use an interface name where a GUID
is required for a reason, and that is part of why it's easier to write COM
applications in Delphi than in MS compilers.
Were your new definition applied globally and none of the APIs actually use the
non-pointer type, we might as well get rid of that feature, as it'd be useless 
then.
> The current definition makes it quite clear that it is in fact a pointer to a 
> GUID.
In MSDN hungarian notation terms, it is very obviously not: REFIID is
notationally different from LPIID (or just plain *IID in argument lists).



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

Re: [Lazarus] Breaking change

[Martok via Lazarus]

Am 23.07.2017 um 14:24 schrieb Michael Van Canneyt via Lazarus:
>> The pointer-ness of REFIID is an artefact of the C-ABI. It is not meant to 
>> mean
>> 'pass a pointer to a GUID-struct', but 'pass a GUID using byref'. We have
>> constref for that.
> 
> See the link to the Windows MSDN.
Yes, so?

REFIID is also the type of the first argument of QueryInterface.


{ IUnknown }
function QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} IID: TGUID; out Obj): Hresult;
virtual; {$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};

But I see already it has been translated differently in every unit (mostly
because MS made it uniform only after the headers were translated), so might as
well use the new one to keep things interesting. Carry on.

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

Re: [Lazarus] Breaking change

[Martok via Lazarus]

Hello,

> I have fixed bug 28760:
>
> https://bugs.freepascal.org/view.php?id=28760
as the reporter: not really.

The pointer-ness of REFIID is an artefact of the C-ABI. It is not meant to mean
'pass a pointer to a GUID-struct', but 'pass a GUID using byref'. We have
constref for that.

> Directly passing an interface where (T)REFIID is expected, will no longer be
possible.
It must be, if only for Delphi compat.

Delphi import is (... const riid: TIID;...), but that only works because they
never seem to pass structured types on the stack, regardless of size.


Martok

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

Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)

[Martok via Lazarus]

Am 03.05.2017 um 11:03 schrieb Juha Manninen via Lazarus:
> How could this thing be communicated so that people understand?
It would probably help if there weren't three different pages about "Unicode
Support" on the wiki, all saying slightly different and conflicting things
(because they talk about different things, but that's really not obvious unless
you already know) and decidedly *not* saying what a user might want to know...

Maybe split the technical internals from a "simpler" user's guide?


Martok

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

Re: [Lazarus] type lib import

[Martok via Lazarus]

Hi,

yes, FPC provides the 'importtl'-utility for that. You can also install the
LazActiveX package to get a Delphi-style visual frontend for it in the IDE Tools
menu.


Martok

Am 04.03.2017 um 16:33 schrieb Marc Santhoff via Lazarus:
> Hi,
> 
> is fpc/lazarus able to import type libraries for COM dll on windows?
> 
> TIA,
> Marc
> 
> 

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

Re: [Lazarus] Lazarus Release 1.6.4

[Martok via Lazarus]

> Yes, this is caused by one of the two changes pf 3.0.2. See
> http://wiki.lazarus.freepascal.org/User_Changes_3.0.2#Classes
> 
Jürgen appears to already have the fixed version, with the correct ifdefs:

>>{$if FPC_FULLVERSION >= 30100}
>>Res:=FSrcStream.Seek(QWord(liOffset), Origin, QWord(liResult));
>>{$else}
>>Res:=FSrcStream.Seek(Int64(liOffset), Origin, Int64(liResult)); <--   
>> oleutils.pas(110,64) Error: Call by var for arg no. 3 has to match exactly: 
>> Got "Int64" expected "QWord"
>>{$endif}

This should work, the error message is in the branch of the conditional that
should not be taken at all...


Martok

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

Re: [Lazarus] Help System with Chromium Embedded component

[Martok via Lazarus]

Am 09.11.2016 um 16:02 schrieb Mattias Gaertner via Lazarus:
> On Wed, 9 Nov 2016 15:57:04 +0100
> Marco van de Voort via Lazarus  wrote:
>> [...]
>> The best reason to have some local (whatever how limited) widget is for IDE
>> popups of helptext instead of an external browser.

That was also one of my reasons, too. It doesn't even have to do everything
modern HTML can (on the part of the layout engine, there haven't really been
that many changes anyway), but something to view rich content (purposefully not
saying 'RichView' here...) would be good to have. HTMLHelp would really just be
one of multiple applications for it.

Am 09.11.2016 um 16:24 schrieb Graeme Geldenhuys via Lazarus:
> The inconsistency of HTML rendering components is a real problem.
Yet another reason against the IE5 of this decade.



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