Recent

Author Topic: bgrabitmap and bgracontrols for Lazarus and Delphi  (Read 9616 times)

Edivando

  • New Member
  • *
  • Posts: 16
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #15 on: November 30, 2018, 04:38:26 pm »
deixe o path do projeto assim c:\bgrabitmap\  que tudo vai funcionar pois o Search path esta estatico com esse caminho

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #16 on: November 30, 2018, 08:01:43 pm »
Great, it's working fine. To work better on Windows 10 I just enable 'Double Buffered' in forms to avoid flickering.

I will try to incorporate BGRAControls changes into our repository.

It will be good if it can run in any folder, not just from C:\bgrabitmap\, because we have 2 repos, one for bgrabitmap and one for bgracontrols, and they are in separate folders.

Anyone with more Delphi experience can help?
« Last Edit: November 30, 2018, 08:03:49 pm by lainz »

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #17 on: December 01, 2018, 01:48:18 am »
Hi, I've merged your changes into our repository of BGRAControls
https://forum.lazarus.freepascal.org/index.php/topic,24176.msg303533.html#msg303533

Please if there are more changes:
- Create a fork of the development branch of BGRAControls, or the master branch is ok too, because I added every change from 5.0.1 to 5.0.3 plus development branch one by one by myself again into the new release.

https://help.github.com/articles/fork-a-repo/

About BGRABitmap changes, I can't add them, that must be done by Circular, but he doesn't have currently a Windows machine to test, so maybe it's good that you can mantain the delphi version.

Many thanks for your help.  :)
« Last Edit: December 01, 2018, 02:07:03 am by lainz »

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #18 on: December 14, 2018, 05:10:44 pm »
If the Delphi version is working, we can start to try and merge what we can into the dev branch.
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #19 on: December 16, 2018, 03:05:04 pm »
I tested bgracontrols and its working.

Is based on BGRABitmap 9.9, so you have 2 options:

1) Use that code and add all your development branch changes to that
2) Add all this version changes to development branch

Maybe 3) If there's a way to merge both changes at the same time.

What I did was take the bgracontrols fork as a base and then I've added all changes in development again.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #20 on: December 17, 2018, 03:50:09 pm »
Hi @Edivando

Thanks for taking the time to make a Delphi version of BGRABitmap.

I agree with the changes regarding the overload keyword. Sometimes it was missing and sometimes I suppose keyword position is not accepted by Delphi. I have merged those changes in the dev branch of BGRABitmap.

There are other changes that we need to talk about. Basically, I would like that the number of change in the code to be the smallest possible to make it easier to maintain.

For example renaming all types like Word -> BGRAWord seems unnecessary to me as there is no ambiguity in the meaning of this type. This may be useful when porting into another language but that's not what we are doing here. What are the types that are not compatible between Delphi and FreePascal that would necessitate an alias? NativeInt? UInt64?

Also about the function LEToN, NToLE, BEToN and NToBE, as they do not exist in Delphi I suggest to emulate those functions, so that the rest of the code is unchanged.

Regarding removing the $PUSH / $POP when it is not FPC, I have some doubts. At the end of the $POP, the options are back to what they were. The switches $HINTS and $OPTIMIZATION are there to fix some compiler problems, so maybe they are not necessary with Delphi and you could include them inside the $IFDEF FPC.

There other things but let's start with that.
Conscience is the debugger of the mind

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #21 on: December 17, 2018, 04:30:46 pm »
For example renaming all types like Word -> BGRAWord seems unnecessary to me as there is no ambiguity in the meaning of this type. This may be useful when porting into another language but that's not what we are doing here. What are the types that are not compatible between Delphi and FreePascal that would necessitate an alias? NativeInt? UInt64?
Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....
Quote
Also about the function LEToN, NToLE, BEToN and NToBE, as they do not exist in Delphi I suggest to emulate those functions, so that the rest of the code is unchanged.
These are functionally supported in some third party networking libraries and Windows units in Delphi (I believe in winsock? because similar routines are needed for network byte order, not only for processor endness). Also  note implementation is platform!
Quote
Regarding removing the $PUSH / $POP when it is not FPC, I have some doubts. At the end of the $POP, the options are back to what they were. The switches $HINTS and $OPTIMIZATION are there to fix some compiler problems, so maybe they are not necessary with Delphi and you could include them inside the $IFDEF FPC.
That's another matter and can indeed lead to code breaks if it can not be determined what the state was at {$push} time. Requires careful code analysis. Delphi does not support it in any version.

The most important pre-requisites for such conversions are:
- determining the supported Delphi minimum version
- and the license model. (e.g. if it is compatible with lgpl+linker exception, you can also copy out the byte order manipulations (LEToN and family) from the fpc code (although that is trivial code if the endness is known).

« Last Edit: December 17, 2018, 04:47:51 pm by Thaddy »
Specialize a type, not a var.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #22 on: December 17, 2018, 06:41:28 pm »
Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....
Sounds contradictory to me. Can you make full sentences here?

About LEToN, NToLE, BEToN and NToBE I suppose it will be little endian, so those functions would simply return the same value.
Conscience is the debugger of the mind

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #23 on: December 17, 2018, 06:55:45 pm »
Not necessary, unless very old versions of Delphi will be supported (pre D2010, maybe even XE2). Many of those types were introduced in FPC because of Delphi compatibility....
Sounds contradictory to me. Can you make full sentences here?
We introduced them, or re-named them, after Delphi started to support 64 bits: NativeInt, NativeUint, etc. This is not an issue if the minimum supported Delphi version would be XE2.
Anyway, if, say D7, needs to be supported it is cheaper to declare them in a Delphi specific block than to introduce specific types.
« Last Edit: December 17, 2018, 06:57:39 pm by Thaddy »
Specialize a type, not a var.

Edivando

  • New Member
  • *
  • Posts: 16
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #24 on: December 17, 2018, 11:09:26 pm »
Boa noite,

Sei que não seria o tópico correto para incluir esses links, porem sei do alto grau de conhecimento das pessoas envolvidas nesse tópico e gostaria das suas opiniões.
O que acha de uma modalidade de  Crowdfunding para agilizar o desenvolvimento de algumas soluções para o Lazarus e FPC?

Links sobre o assunto:

https://forum.lazarus.freepascal.org/index.php/topic,43543.0.html
http://pas2js.38893.n8.nabble.com/
http://free-pascal-lazarus.989080.n3.nabble.com/

Atenciosamente

Edivando, Brasil

----------------------------- Google Translate -------------------------------------

Good night,

I know it would not be the correct topic to include these links, but I know the high degree of knowledge of the people involved in this topic and would like the opinion of you.
What do you think of a Crowdfunding modality to speed development of some solutions for Lazarus and FPC?

Links on the subject:

https://forum.lazarus.freepascal.org/index.php/topic,43543.0.html
http://pas2js.38893.n8.nabble.com/
http://free-pascal-lazarus.989080.n3.nabble.com/

graciously

Edivando, Brazil

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #25 on: December 18, 2018, 10:42:19 am »
We introduced them, or re-named them, after Delphi started to support 64 bits: NativeInt, NativeUint, etc. This is not an issue if the minimum supported Delphi version would be XE2.
Anyway, if, say D7, needs to be supported it is cheaper to declare them in a Delphi specific block than to introduce specific types.
Well precisely I am trying to narrow down the types that may need some hack. And indeed, it is easy to declare NativeInt if it is missing rather than renaming in the whole source code.

@Edivando:
That's off-topic. By the way have you seen my questions/remarks?
Conscience is the debugger of the mind

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #26 on: December 18, 2018, 12:55:46 pm »
Note there are some problems with Delphi because the native types are declared wrong in d2007,2009 and 2010.
So if you declare them, do it like so:
Code: Pascal  [Select][+][-]
  1. {$if CompilerVersion<=21}
  2. type
  3.   NativeInt = Integer;
  4. ... etc
  5. {$ifend}
« Last Edit: December 18, 2018, 01:01:12 pm by Thaddy »
Specialize a type, not a var.

circular

  • Hero Member
  • *****
  • Posts: 4195
    • Personal webpage
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #27 on: December 19, 2018, 01:22:19 pm »
Thanks for the tip
Conscience is the debugger of the mind

DomingoGP

  • Jr. Member
  • **
  • Posts: 60
Re: bgrabitmap and bgracontrols for Lazarus and Delphi
« Reply #28 on: April 07, 2019, 10:10:40 am »
Hi Edivando
I have been testing the library a bit and I have found and fixed 2 bugs. I have also implemented the functions LEToN, BEToN ... for delphi.
I have put 3 pull requests in your repository on GitHub in case you may be interested in the changes made.

 

TinyPortal © 2005-2018