* * *

Recent Posts

Pages: [1] 2 3 ... 10
1
Graphics / Re: BGRABitmap Thread Problem in Android
« Last post by mercury on Today at 02:28:49 pm »
I solved them by adding some standard functions from here:
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.StaticLinking.pas
This pasvulkan project is amazing! All thing I want -- cross-platform framework with Sprites/Audio/Canvas/Font/GUI. But I think neither my computer nor android device support vulkan. And I guest most people don’t have any device support it. May I can use this framework several years later. As now I better stuck with SDL2 which gives most compatibility (DirectX/OpenGL).
2
I can use zlib to decompress then?
Forgive my ignorance but, why would you want to do do that manually ?

fcl image seems to support deflate (according to the wiki that user Handoko linked to) so either using fcl-image or TTiffImage/TPicture should be able to get you going.
3
Graphics / Re: BGRABitmap Thread Problem in Android
« Last post by mercury on Today at 01:55:05 pm »
I-net = Internet  :)
Is this abbreviate really used commonly?

When compiling for Windows, compilation failed due to linking errors.
I solved them by adding some standard functions from here:
https://github.com/BeRo1985/pasvulkan/blob/master/src/PasVulkan.StaticLinking.pas
I was wondering if the archive you included with your first post compiles out-of-the-box on your system for Windows ?
If not, please include a fully functional project. Again, to prevent differences between our setups.
Maybe you used a different compiler (change the static linked libs to fit compile you used should work). What I used is download from here:
https://sourceforge.net/projects/mingw-w64/files/Toolchains targetting Win32/Personal Builds/mingw-builds/4.9.3/threads-posix/dwarf/

The source code I uploaded is fully functional project (yet not finished like sound/draw/etc.).
I uploaded the lib+bin I compiled for win32. (Three mirrors are the same.)
https://uploadocean.com/33gu9fh5ptro
https://www.sendspace.com/file/brb5aq
https://bdupload.info/udtquqau6z5p

With these libs you should compile the same binary as mine (and with FPC 3.0.2).
4
That reminds me of the time i was using a  sorted TStringList as a map and then it suddenly stopped worked.

Because I was creating the TStringList in the initialization section and some other unit was installing a wide string manager in their initialization section, but after I had created the list.

Then AnsiCompareStr was another function during the list creation than it was using during the list usage, and the formerly sorted stringlist was unsorted according to the new compare function.

You still miss the point: the widestring manager should not affect AnsiString. AnsiString behavior is fixed, not variable....

But the widestring manager changes everything. It always has.

That is why I do not use the Ansi* functions and write all Unicode functions I need myself.

5
Thanks for info Mick,

compression tag value = 8 and I suppose
I can use zlib to decompress then?

Regards
stab ::)
6
You still miss the point: the widestring manager should not affect AnsiString. AnsiString behavior is fixed, not variable.... <sigh> It breaks code... that's enough to file the bug.

Breaks code, or unexpected sort order due to locale?
7
You still miss the point: the widestring manager should not affect AnsiString. AnsiString behavior is fixed, not variable.... <sigh> It breaks code... that's enough to file the bug.
8
General / Re: Extract path of a windows shortcut
« Last post by rvk on Today at 01:08:20 pm »
Something like this:

Code: Pascal  [Select]
  1. uses ActiveX, ShlObj, Windows;
  2.  
  3. function GetLnkTarget(const LnkFilename: widestring): string;
  4. var
  5.   ShellLink: IShellLink;
  6.   PersistFile: IPersistFile;
  7.   Info: array[0..MAX_PATH] of char;
  8.   FindData: TWin32FindData;
  9. begin
  10.   Result := '';
  11.   CoCreateInstance(CLSID_ShellLink, nil, CLSCTX_INPROC_SERVER, IShellLink, ShellLink);
  12.   if ShellLink.QueryInterface(IPersistFile, PersistFile) = 0 then
  13.   begin
  14.     PersistFile.Load(PWideChar(LnkFilename), STGM_READ);
  15.     ShellLink.GetPath(@Info, MAX_PATH, FindData, SLGP_UNCPRIORITY);
  16.     Result := Info;
  17.   end;
  18. end;
  19.  
  20.  
  21. procedure TForm1.Button1Click(Sender: TObject);
  22. begin
  23.   Showmessage(GetLnkTarget('path_and_filename_to_your_lnk_file.lnk'));
  24. end;
(tested in Windows 10, not tested in Windows XP)
9
Therefore, it would seem that under C# a unicode comparison of 'a' and 'B' returns 'a' < 'B'.

Thank you!

 8-) <sigh> C# does not suffer this bug. EganSolo reached the opposite conclusion for the information given:

Again, his result: 'a' and 'B' returns 'a' < 'B'
lowecase a before uppercase B, unlike the expected ANSI/ASCII order.

Quote
Quote
A string is a sequential collection of Unicode characters that is used to represent text. The value of the String object is the content of the sequential collection of characters

Therefore, it would seem that under C# a unicode comparison of 'a' and 'B' returns 'a' < 'B'.
The latter means on most latin codepages C# treats 'a' >' 'B' because 'B' has a lower sequential index in the ASCII compatible part of the unicode tables.

You reversed the direction. Intentional or mistake?

In WinAPI the result is correct
In C# the result is correct
In Java the result is correct.
In Delphi the result is correct
In Freepascal it fails


Note compare functions can be both case sensitive and case insensitive. That should be obeyed. For TStringlist to work as intended and transparently regardless of a string manager it should use e.g. LOCALE_INVARIANT on Windows. That's the whole point...

LOCALE_INVARIANT gave me the same results of LOCALE_SYSTEM_DEFAULT, lowercase before uppercase.

A TStringlist is not a display format. And A widestring mananager should not affect AnsiString if the default stringtype is Ansi.

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Classes_TStringList_Sort.html

I am fully aware of:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/SysUtils_AnsiCompareStr.html
Which may have lead to this misunderstanding. Point is: something should be done, either docs or code

Thank you for finding the source. Quoting it here:
Quote
Note: Most locales consider lowercase characters to be less than the corresponding uppercase characters. This is in contrast to ASCII order, in which lowercase characters are greater than uppercase characters. Thus, setting S1 to 'a' and S2 to 'A' causees AnsiCompareStr to return a value less than zero, while CompareStr, with the same arguments, returns a value greater than zero.
10
lowercase before uppercase, unlike ANSI/ASCII.
And that is the bug... I am fully aware of the technical details, but installing a widestring manager should not cause sort-order changes to AnsiString. The rest is overcomplicating things.

The widestring or unicodestring manager should not affect the AnsiString internals in any way. They are different beasts... We do not even have a TStringlist for unicode in classes yet...
Pages: [1] 2 3 ... 10

Recent

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