* * *

Recent Posts

Pages: [1] 2 3 ... 10
Third party / Re: Instagram scraper class
« Last post by crack81 on Today at 10:15:35 pm »
Thanks for share, I will try it more later and give you my feedback.
Please submit this as a bug report.

I was just working today with a group of people explaining the use of my software, and one person using Mohave was getting strange behavior with certain forms not appearing. The software was built using Lazarus trunk with cocoa. The software does not show this behavior on El Capitan.

The cocoa widgetset is rapidly improving, but bug reports are essential to the process.

Networking and Web Programming / Re: Indy10 TIdHTTP gzip issue
« Last post by asdf121 on Today at 09:38:41 pm »
recently I noticed that gzip does not work with TIdHTTP anymore. It just returns garbage.

Your test code works fine for me on Windows, at least (I'm not a Linux user).
Yes, on windows it's working fine for me too now - was just an issue with 32/64bit zlib.


(Un)defining that in your own code has no effect on Indy.  It needs to be (un)defined in Indy's IdCompilerDefines.inc file instead, and then recompile Indy.
It's only defined in IdZLibConst and IdZLibHeaders, seems it's does even not support FPC at all. First statement is always $UNDEF.
Btw, why are the included zlib linking files so ancient?

//Request.AcceptEncoding := 'gzip';
Request.AcceptEncoding := 'deflate';

Note that you cannot force TIdHTTP to use only deflate when a Compressor is assigned.  If the Compressor is loaded successfully (its IsReady property is true), TIdHTTP will automatically add gzip and/or deflate as needed to the Request.AcceptEncoding if they are not already present, thus allowing the server to choose between them.

Because TIdHTTP auto-sets the Request.AcceptEncoding if the Compressor is ready, you should not set the AcceptEncoding manually at all, or at least not for gzip/deflate specifically.  You should let TIdHTTP enable gzip/deflate for you only if the Compressor is able to handle them.

That is likely the root cause of your problem.  The Compressor is not ready (for whatever reason), so TIdHTTP does not update the Request.AcceptEncoding, so your manual setting gets passed as-is to the server, which then sends back a compressed response (not garbage) that TIdHTTP does not auto-decompress for you.

So, either figure out why the Compressor is not loading correctly, or else leave the Compressor set to nil, set the Request.AcceptEncodings as needed, and then handle the decompression manually after the compressed response is returned to you.
Okay, I'll remove my Request.AcceptEncodings line and let TIdHTTP decide.

But the issue on linux still exist, maybe it's related to the change of SSLDLLVers, Bug fix for HackLoad() and Updating various DLL related functions

It should not be related, since those changes do not affect how Indy uses Zlib.

where the last one says
// TODO: setup this array more like the SSLDLLVers arrays in the IdSSLOpenSSLHeaders unit...

The changes I made for handling OpenSSL DLLs do not apply to ZLib DLLs.  So, if ZLib was loading correctly before, it should still load OK now, I did not change that logic.
Well, you changed the function to load a library which is also used for zlib. I only can tell you what I noticed, with older Indy version it loads it correctly and with a newer one TIdHTTP fails to decompress gzip but uses gzip (own hardcoded Request.AcceptEncodings removed). I don't know where to search exactly but there must be an issue somewhere.

However, note that both IdSSLOpenSSLHeaders.Load() and IdZLibHeaders.Load() do not raise an exception on load failure, they return Boolean values instead, eg:
Thanks for the hint, didn't knew before. Only noticed that IdSSLOpenSSLHeaders.Load() raises an exception when OpenSSL library not found. Guessed IdZLibHeaders.Load() would do the same.

when using gzip, the internal check does only check if Compressor is not nil which is also true if loading zlib failed -> returning garbage.

TIdHTTP checks the Compressor.IsReady property before updating the Request.AcceptEncoding, or decompressing a compressed response.
I'll test again with checks for Compressor.IsReady which should be true, else it shouldn't ask for gzip at all, correct? And without gzip enabled and zlib not working, I shouldn't receive garbage...
LCL / Re: TDirectoryEdit.Longname ?????????
« Last post by CM630 on Today at 08:48:48 pm »
It is now in LazFileUtils.
General / Re: Using inherited from direct TObject descendant.
« Last post by damieiro on Today at 08:43:29 pm »

That inherited would call allways to an empty TObject.Create, there is an ancestor class.  If the inherited is TObject is that inherited supressed or compiler makes a call and a return for nothing? (unless optimized again)..

I agree with the code style, but i do not see TObject as a pure ancestor (do init things that aren't called by create constructor and it has not any class constructor). This is the way we difer. The style you propose it's solid even without ancestor method. So i really agree with that even more with the Aserge explanation. For example.

Code: Pascal  [Select]
  1. type
  2.   MyClass= class
  3.     public
  4.       mydata:TmyData;
  5.       constructor create (data:word);virtual;
  6.       destructor destroy; override;
  7.   end;
  9. constructor MyClass.Create (data:word);
  10. begin
  11.   inherited;  {there is not such ancestor and this call is removed from compiler}
  12.   {do constructor things}
  13. end;
  15. destructor MyClass.destroy;
  16. begin
  17.   {do destructor things}
  18.   inherited;
  19. end;

But with TObject.create (without parameters) this call should be allways treated as in this example (inherited removed by compiler), not making me a chain of unnecesary inherited to an object that never should have code being called. I'm not sure of this case and i do not like in the .create without parameters for that reason..
Really i do not know why a .create constructor is defined as default in Tobject... It should work better without that definition
General / Re: Static linking
« Last post by DonAlfredo on Today at 08:21:34 pm »
You can add this file into your project:


It will provide the necessary functions for static linking.
GTK / Re: Shift+Num7 must give Shift+Home, but gives only Home
« Last post by Blaazen on Today at 08:15:21 pm »
So I tested Kate:
NumLock Off: Home / Shift+Home
NumLock On: 7 / Home

It seems there are no two widgetsets and applicarions with the same behaviour. :)
GTK / Re: Shift+Num7 must give Shift+Home, but gives only Home
« Last post by Blaazen on Today at 08:10:41 pm »
My tests was also with laptop keyboard. Yes, it's better to have real Home/End keys.
GTK / Re: Shift+Num7 must give Shift+Home, but gives only Home
« Last post by Martin_fr on Today at 08:09:01 pm »
Just tested, in gedit "num7" acting as "home" (numlock off) can not be used with shift to get shift-home. It will instead insert "7" into the text. With numlock, it is always "7".
Fedora 28
Pages: [1] 2 3 ... 10


Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus