Comments for jed-software.com

Comment on Embarcadero: Don’t hide behind bad design by Haizhou

Haizhou — Sun, 05 May 2013 11:31:58 +0000

Not surorised. That is why Delphi was a good RAD tool, but the team control its destiny never took off the ground, eventurally fell apart. They are not market/customer oriented, but their R&D driven biz. Hope Marc’s employment can change this a bit, otherise, they wont catch the mobile/tablet new wave either. lets all pray.

Comment on Embarcadero: Don’t hide behind bad design by Peter Wright

Peter Wright — Sat, 04 May 2013 14:00:17 +0000

Amen. If we close our eyes and deny there are problems, it’ll all go away.

So do the customers – a fact with which they stubbornly also seem to deny.

Comment on Embarcadero: Don’t hide behind bad design by Eric

Eric — Thu, 02 May 2013 06:03:14 +0000

That kind of QC bug closing is quite widespread, with “won’t do” and “can’t reproduce” (for blatantly trivial to reproduce issues) are one of the key factors behind the surge of QC entry getting closed during the last year. Actual bug fixes are rare, and design fixes are even rarer.

Comment on FireMonkey: Extending TFloatAnimation to support maximum loops by JED

JED — Mon, 11 Feb 2013 19:13:16 +0000

While it could be considered dangerous since we have the source code for FireMonkey this helps remove much of the danger. This was never intended to be a change that lasts forever. Ultimately it is up to Embarcadero to put such a feature in the framework soon.
Without RTTI, adding the necessary property and functionality to an existing class in someone elses framework, probably wouldn’t be worth the hassle.

Comment on FireMonkey: Extending TFloatAnimation to support maximum loops by Markus J.

Markus J. — Mon, 11 Feb 2013 08:59:44 +0000

In my opinion, accessing private fields with RTTI is dangerous. Private fields or methodes are allowed to change in the future. So, there is a great potential to introduce runtime errors in future versions, which are hard to detect.
IMHO, RTTI can cause more problems then solving them. The errors will occur when maintaince begin, and it will be very hard to detect them. When you use RTTI heavily and you are using refectoring tools, it will become a nightmare.

Comment on XE Plus Pack – Release 11 by JED

JED — Thu, 03 Jan 2013 17:58:01 +0000

Further information about XE Plus Pack is available at: http://www.jed-software.com/xepp.htm

Comment on XE Plus Pack – Release 11 by Steven

Steven — Wed, 02 Jan 2013 19:36:51 +0000

For those who have never heard of the Xe Plus Pack – little more info and link would be helpful.

Comment on Fixing FireMonkey: TMemo/TEdit – OnExit by Steve

Steve — Wed, 02 Jan 2013 11:53:15 +0000

>> Perhaps this should have triggered the developer making that change, to actually fix the issue in the ancester class
>
> Maybe it was the same developer who worked on the VCL Styling code where “he” added code to paint the TGraphicControl child controls in 3 components instead of painting them in the base class so that they would have been painted in all controls.

More of an answer to Andreas’s comment:
Seems a symptom of Agile / Scrum Software Development (at least from my experience) (and as far as I know, I think FM is built this way too), where there is little context of the “big-picture” of the product or feature and have different people working on similar types of code, that should ideally have been done by one person as they all related. So instead of implementing a feature more elegantly in one place (such a base class), instead similar code is duplicated all over the place, because there are 3 Scrum stickies that say…
“1) Implement TGraphicControl painting in class X”, “2) Implement TGraphicControl painting in class Y” and “3) Implement TGraphicControl painting in class Z”.

And to improve efficiency to let 3 different developers of different skills each implement it in “parallel” (each unaware what method the other is using – and end up with 3 different pieces of code (and quality) to really one problem… to draw a TGraphicControl … so rather than see it’s the same type of code really, that should be implemented by one person so that you end up with a more consistent and elegant solution

Comment on Fixing FireMonkey: TMemo/TEdit – OnExit by Andreas Hausladen

Andreas Hausladen — Tue, 01 Jan 2013 12:33:20 +0000

> Perhaps this should have triggered the developer making that change, to actually fix the issue in the ancester class

Maybe it was the same developer who worked on the VCL Styling code where “he” added code to paint the TGraphicControl child controls in 3 components instead of painting them in the base class so that they would have been painted in all controls.

Comment on Office closing for a week (plus what’s coming up) by ObjectMethodology.com

ObjectMethodology.com — Wed, 21 Nov 2012 15:40:33 +0000

Yep! Long weeks in Australia. Is there less weeks in a year or more days in a year?