Recent

Author Topic: Backwards compatibiliy broken (again)  (Read 20597 times)

eny

  • Hero Member
  • *****
  • Posts: 1587
Backwards compatibiliy broken (again)
« on: August 17, 2009, 07:44:37 pm »
Because of this bug I downloaded the latest SVN version and tried reproducing it.
Reproducting and confirming the bug worked.
But to my horror I discovered that a package wouldn't compile anymore. What happened?
PWindowInfo (in Win32proc.pp) was renamed to PWin32WindowInfo.
WT*  >:(  (one-Mississippi, two-Mississippi.....)

Making these kind of dramatic changes in between versions creates a maintenance nightmare (hell, there hasn't even been a minor version number change: 0.9.27 from June 2009 doesn't have this 'feature').
Design 'decisions' like this are a great way to get rid of all these pesky Lazarus users.
PEBKAC! Who need's users anyway...


In the end it it appeared to be 2 changes (i.e. procedure call renames) that I managed to make myself in the lclextensions package.
Nevertheless, one get's very nervous when things suddenly stop working.
This doesn't help the Lazarus adoptation process...
« Last Edit: August 17, 2009, 08:00:36 pm by eny »
All posts based on: Win10 (Win64); Lazarus 1.8.0 'stable' (#56594 win64) unless specified otherwise...

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5695
    • wiki
Re: Backwards compatibiliy broken (again)
« Reply #1 on: August 18, 2009, 12:44:29 am »
I havent'  to much of an answer. But I checked the SVN log entry

 12/07/2009 05:27:59           
win32: rename TWindowInfo -> TWin32WindowInfo, GetWindowInfo -> GetWin32WindowInfo, etc because of conflict with winapi functions and structures

So there was some reason...


as for "there hasn't even been a minor version number change: 0.9.27 from June 2009 doesn't have this 'feature"

0.9.27 is not a released version, the last released version was 0.9.26.2, the next one will be 0.9.28
So the change you mention will be between those 2 versions, and hence there will at least be a change in the version number (even so I do understand this is the lesser of the issues you have with this whole thing)

0.9.27 is a kind of place holder version for the development version. every day several changes are committed, overall between to releases there will be several 1000 commits. it is not possible to give each of them a new version

eny

  • Hero Member
  • *****
  • Posts: 1587
Re: Backwards compatibiliy broken (again)
« Reply #2 on: August 18, 2009, 08:08:10 am »
I understand where the change is coming from.
But Lazarus has somewhat of a critical mass I would say.
So breaking backwards compatibility like this will make people, well, nervous.
Especially because 0.9.27-xxxxx is miles ahead of 0.9.26.

The silver lining is that the latest version has a fix for the open directory dialog :D
All posts based on: Win10 (Win64); Lazarus 1.8.0 'stable' (#56594 win64) unless specified otherwise...

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #3 on: August 18, 2009, 11:36:24 am »
TWindowInfo was and TWin32WindowInfo is some internal widgetset structure which shouldn't be used in lcl/user applications.
Using internal structures in your own code is at your own risk. They may change without any notice or backward compatible solution.
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

eny

  • Hero Member
  • *****
  • Posts: 1587
Re: Backwards compatibiliy broken (again)
« Reply #4 on: August 18, 2009, 02:55:35 pm »
I never use 'internal' procedures.
But there were used in the lclextensions package that are a prerequisite for VirtualStringTree. And that I do use.
In fact, the availability of this component is one of the main reasons to use Lazarus.
All posts based on: Win10 (Win64); Lazarus 1.8.0 'stable' (#56594 win64) unless specified otherwise...

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #5 on: October 12, 2009, 03:00:22 pm »
maybe the lcl extentions should be integrated into the lcl
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

zeljko

  • Hero Member
  • *****
  • Posts: 1079
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Backwards compatibiliy broken (again)
« Reply #6 on: October 12, 2009, 09:47:43 pm »
maybe the lcl extentions should be integrated into the lcl

I vote for this.
lcl extensions is a "must have" when porting from Delphi to LCL.

DRIGUS

  • Jr. Member
  • **
  • Posts: 59
Re: Backwards compatibiliy broken (again)
« Reply #7 on: October 13, 2009, 08:41:38 am »
maybe the lcl extentions should be integrated into the lcl

  About two weeks before I tried to use the new VirtualTrees package on Windows CE, which depends on LCLExtensions (and MULTILOG). If I remember rightly I even can't compile a simple test project because of missing identifiers used in the LCLExtensions package. And yes, I used the latest svn snapshots.

Greetings,
  Björn
DRIGUS GmbH

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #8 on: October 13, 2009, 10:52:16 am »
Made a bugreport for this so I won't forget
http://bugs.freepascal.org/view.php?id=14792
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

zeljko

  • Hero Member
  • *****
  • Posts: 1079
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Backwards compatibiliy broken (again)
« Reply #9 on: October 24, 2009, 09:26:02 pm »
  About two weeks before I tried to use the new VirtualTrees package on Windows CE, which depends on LCLExtensions (and MULTILOG). If I remember rightly I even can't compile a simple test project because of missing identifiers used in the LCLExtensions package. And yes, I used the latest svn snapshots.

Greetings,
  Björn

Which widgetset/OS ? I'm using it with qt on windows,linux and mac and it works ok.

DRIGUS

  • Jr. Member
  • **
  • Posts: 59
Re: Backwards compatibiliy broken (again)
« Reply #10 on: October 26, 2009, 10:29:43 am »
Which widgetset/OS ? I'm using it with qt on windows,linux and mac and it works ok.

  Take a closer look at my post ;).


Greetings,
  Björn
DRIGUS GmbH

zeljko

  • Hero Member
  • *****
  • Posts: 1079
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Backwards compatibiliy broken (again)
« Reply #11 on: October 26, 2009, 12:27:52 pm »
Yes ... see CE now :)

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #12 on: January 03, 2010, 03:55:21 pm »
Finally I took some time to look at the package and decided not to add it for the following reasons:

function CreateBitmapMask:
First, creating a mask is already part of TRasterImage.
Second, some implementations are empty

function DirectMaskBlt:
Comment says it all, this is a stripped version of LCL.StretchMaskBlt
I see no reason to add duplicate code.

function OptimalPixelFormat:
This always should be pfDevice, if not then there is something else wrong.

function OSSupportsUTF16:
this is an OS function not a widgetset function, so it doesn't belong here
This flag shouldn't be needed anyway, the LCL is always utf8, when dealing with OS functions, use the proper SysXXX conversion routines
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

zeljko

  • Hero Member
  • *****
  • Posts: 1079
    • http://wiki.lazarus.freepascal.org/User:Zeljan
Re: Backwards compatibiliy broken (again)
« Reply #13 on: January 03, 2010, 04:28:04 pm »
Well, those functions aren't "something special" for LCL, mainly but for delphi compatibility AFAIK, so I would propose delphi extensions as package then, instead of out-of-lazarus-repo svn.
Maybe we can ask Luiz to add it to lazarus-ccr ?

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2496
Re: Backwards compatibiliy broken (again)
« Reply #14 on: January 03, 2010, 04:47:41 pm »
Oops, I forgot about the more interesting delphicompat.pas
Reopened
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker