Jump to content
Ian Branch

D11 - A bridge too far.. :-(

Recommended Posts

If anybody is interested.

In going back to D10.4.2 from D11 I had to remove multiple 'PixelsPerInch = 96' from my .dfm files.

D10.4.2 didn't like them either at design time, but not always, or, having built OK, the App(s) failed at Run time due to the line presence in the .dfms. 

All good now.

  • Like 1
  • Thanks 1

Share this post


Link to post
1 hour ago, Alberto Fornés said:

maybe Embarcadero could offer that version at a lower price and establish a more honest relationship.

Why should they? There apparently are enough people who pay the full price for the privilege of becoming beta testers. And I have to include myself in that. (OK, it's not my own money. I wouldn't pay for this.)

Share this post


Link to post
1 hour ago, Ian Branch said:

I had to remove multiple 'PixelsPerInch

 

 

  • Like 1

Share this post


Link to post
13 hours ago, Uwe Raabe said:

Who says that they weren't?

A salient point. 

 

And then there are the high dpi issues from 10.4.2 that were ignored 🙄 

Share this post


Link to post
14 hours ago, Alberto Fornés said:

Maybe if you don't have the human resources and / or time to do a good test and find bugs before releasing the product, and you hope that the customers will find and report them, maybe Embarcadero could offer that version at a lower price and establish a more honest relationship.

The thing is, releasing software that is of low quality means that your engineering team spends large amounts of time addressing this low quality post release when it is much more expensive to do so. If they would use better engineering processes and concentrate on quality from the very start, then they would use far less human resources. They aren't even cutting corners with this approach. It is inefficient in terms of their own times and resource, and obviously really inefficient for every user affected by this low quality. 

Edited by David Heffernan
  • Like 3

Share this post


Link to post
12 hours ago, Alberto Fornés said:

Maybe if you don't have the human resources and / or time to do a good test and find bugs before releasing the product, and you hope that the customers will find and report them, maybe Embarcadero could offer that version at a lower price and establish a more honest relationship.

Or make unit tests open source and ask community to join them. This would help at least keeping lib in stable state.

  • Like 3

Share this post


Link to post
44 minutes ago, Fr0sT.Brutal said:

Or make unit tests open source and ask community to join them. This would help at least keeping lib in stable state.

This would be too late to make much difference. The longer you leave bugs the more they cost. And I'm not sure that it would even help much. You'd have to devote significant resource to running the community contributors. Better to use that resource to get the quality right from the off. There's just something rotten in the Emba development model. 

  • Like 1

Share this post


Link to post
17 hours ago, FredS said:

Unfortunate History tells me that this is when the real headaches get started.. unlike everyone that wants a bug report with full details from coders, the end user base usually just tosses it out and don't even bother to report those 'unknown' issues..

 

 

yeah, but they keep paying their annual maintenance. If they'd tell EMBT they won't renew until a better job is being done on fixing the last release instead of just rolling the existing issues forward and then piling on more in the next release, they might actually do something to address this. It has been their SOP for years now!

  • Like 1

Share this post


Link to post

The problem with beta testing new releases of Delphi is that the components we use in our applications are normally not available at that time, so it is a pointless exercise. I have given up participating.

  • Like 1
  • Thanks 1

Share this post


Link to post
14 minutes ago, KenR said:

The problem with beta testing new releases of Delphi is that the components we use in our applications are normally not available at that time

I didn't have these problems. All 3rd party libraries I use come with sources and can be adapted to a new Delphi version in a reasonable time frame even without any help of the vendor. Usually I can compile my main project within 1 - 2 days after the first beta drop.

 

There are differences in the effort needed for each library, though. Not everyone took an update friendly approach.

  • Like 4

Share this post


Link to post
29 minutes ago, KenR said:

The problem with beta testing new releases of Delphi is that the components we use in our applications are normally not available at that time

You should buy only components delivered with full source code. And more: you should rebuild the components as part of your application project group to be sure you have all the bits and pieces of the components. Never use prebuild dcu nor dll!

 

Then as @Uwe Raabe said above, you'll will probably never be annoyed to much with new Delphi compiler. Most of the time only minor adjustments are required and vendor is not needed.

 

If you really need the vendor and you are an experienced Delphi developer then stop using those components. They are not well written or the vendor want to lock you with his product and force you to buy an upgrade.

  • Like 3

Share this post


Link to post
2 hours ago, FPiette said:

They are not well written or the vendor want to lock you with his product and force you to buy an upgrade.

I wouldn't go as far as that but certainly there have been plenty of high end components where the source didn't compile. This tells me that few or none do this anymore.. used to be the norm..

  • Like 1

Share this post


Link to post

Hi Team,

I have reached what seems to be a working compromise.. ;-)

I am designing, developing, testing, etc in D10.4.2.

Then when I am satisfied all is OK I do a final Build in D11.

This is seemingly giving me the best of both worlds...

1.  I am working in a known development environment with all the tools I am familiar with.

2.  The final build incorporates the D11 code improvements incorporated.

3.  Not overly critical but the final .exe files are slightly smaller.

 

Now.  If I could get the D10.4.2 IDE to build with the D11 Compiler & libraries, I wouldn't have to switch... ;-)

 

I hold hope for D11 Patch 2 or even later D11.1.

 

Ian

 

Share this post


Link to post
On 10/20/2021 at 7:44 PM, Alberto Fornés said:

Maybe if you don't have the human resources and / or time to do a good test and find bugs before releasing the product, and you hope that the customers will find and report them, maybe Embarcadero could offer that version at a lower price and establish a more honest relationship.

 

or open source the IDE + everything, apart from compilers. Have a licenses that protects EMB investment but allows Pull Requests and co-development with community

 

  • Like 1
  • Thanks 1

Share this post


Link to post
2 hours ago, David Champion said:

 

or open source the IDE + everything, apart from compilers. Have a licenses that protects EMB investment but allows Pull Requests and co-development with community

 

At least open source the VCL and RTL

Share this post


Link to post
11 minutes ago, hsauro said:

At least open source the VCL and RTL

Not going to happen. And neither the IDE.

 

We have had this discussion too many times already.

  • Like 1

Share this post


Link to post
11 hours ago, dummzeuch said:

Not going to happen. And neither the IDE.

 

We have had this discussion too many times already.

I know it’s discussed before but there is not harm in suggesting it again. Some Embarcadero employees read these forums.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×