[DUG] XE Upgrade

Jolyon Smith jsmith at deltics.co.nz
Tue Aug 31 17:41:17 NZST 2010 

> It is pretty lame but it was really a "Quick Fix" measure to pump 
> up the QC figures - in my opinion.

That sort of thing goes on?  <gasp>  ;)


> > e.g. File New VCL Application, rename form as MainMenu (yielding a form
> > class name of TMainMenu) then drop a TMainMenu component on it.

> I noticed that one. Luckily it won't ever effect me but I could see it
> being annoying the first time you were trying to figure out what was
> going on.


Yep, exactly.  The same could be said (had never/would never affect me) of a
huge number of the QC items that *have* been address of course, and it is
the sort of thing that should be fixed as it is the sort of thing that is
*most* likely to strike a newbie (I was already a relatively old hand when I
encountered it, and it still had me scratching my head).

Currently (D2010) if you end up with a form called "MainMenu" (classname
TMainMenu) and a TMainMenu component on it, all is well (compiles, runs,
saves, loads etc) but when you run you get a stack explosion presumably due
to recursion caused by TMainMenu loading a TMainMenu.

To fix this you can qualify the component class (perfectly valid and
legitimate ObjectPascal):

  TMainMenu = class(TForm)
     MainMenu1: Menus.TMainMenu;
  End;

Which fixes the problem but when you do things to make the form design dirty
(at least I think that's the trigger) the IDE complains that the component
should be of type "MenusTMainMenu" and offers to fix it for you.

1) it's wrong, clearly (MenusTMainMenu is not the correct decl)

2) it doesn't fix it, it removes the unit qualification generously restoring
the runtime stack explosion

This is the part that's different from the original report

It's a scenario that is or should be easily detected/pre-empted (it
currently is, but is handled incorrectly) and the IDE more helpful in the
way that it fails.



>
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
On
> Behalf Of Jeremy North
> Sent: Tuesday, 31 August 2010 16:30
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] XE Upgrade
>
> I had a look at your items. A couple of items are suggestions for new
> directives/reserved words. These decisions are not taken lightly.
> Especially prior to the new back end compiler.
>
> A lot of these were made during the time Danny was looking after the
> compiler, it is no secret he wasn't a fan of adding new reserved
> words/directives. Just look at the namespace debacle.
>
> I think this one has been addressed, there is a TopForm boolean
> parameter now. Been there for a while as well I believe.
>
> Report No: 2392          Status: Reported
> Implementation of GetParentForm (Forms unit) is erroneous/incomplete
> http://qc.embarcadero.com/wc/qcmain.aspx?d=2392
>
>
>>> Which raises the question of what a “fixed/closed QC entry” actually
> means,
>
> There should also be a "Resolution" assigned to the report. This will
> give more information. A "Fixed" bug should state the version it was
> fixed in. A closed bug will state a reason for closure. Such as "Can't
> Reproduce" or "Won't do" etc etc.
>
> The internal system generally has more information regarding the
> reason, but rarely is that transferred to the QC item. I reported this
> which is open but personally I don't see it being addressed.
>
> Report No: 20307          Status: Open
> When a report has its status pulled from RAID, a comment about the
> final status should be mandatory
> http://qc.embarcadero.com/wc/qcmain.aspx?d=20307
>
>
>
> I've got over 180 open/reported reports out of over 400. You aren't
> the only one not seeing action on qc reports.
>
>
>
> On Tue, Aug 31, 2010 at 2:05 PM, Jolyon Smith <jsmith at deltics.co.nz>
wrote:
>> Some had certainly not been addressed as of Delphi 2010.  These are
> unlikely
>> to have been addressed in XE either since their status already suggests
> that
>> they are considered fixed (or in the case of suggestions/enhancements,
>> implemented) when they are not.
>>
>>
>>
>> Which raises the question of what a “fixed/closed QC entry” actually
> means,
>> if things can be fixed/closed with nothing actually having been done (or,
>> let’s be generous, whatever has been done subsequently undone or at least
>> not properly tested).
>>
>>
>>
>>
>>
>> From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
> On
>> Behalf Of Colin Johnsun
>> Sent: Tuesday, 31 August 2010 15:49
>>
>> To: NZ Borland Developers Group - Delphi List
>> Subject: Re: [DUG] XE Upgrade
>>
>>
>>
>> Hi Jolyon,
>>
>>
>>
>> On 31 August 2010 13:12, Jolyon Smith <jsmith at deltics.co.nz> wrote:
>>
>>
>>
>> I might be more impressed if they had actually fixed some of the bugs I
>> myself reported that have languished in QC for 8+ years (and had not
>> introduced new ones related to those in the meantime).
>>
>>
>>
>>
>>
>> Just curious, did they ever get around to fixing those reported bugs this
>> time round. From my understanding of the history of Delphi, during that
> time
>> (8 years ago) Borland really turned its back on Delphi in its push to get
>> away from its dev tool roots. But in the last year or two EMBT had made a
>> big effort to address those concerns and really tackle a lot of those
> cases
>> in QC. Did they deliver?
>>
>>
>>
>> Cheers,
>>
>> Colin
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at delphi.org.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
>> unsubscribe
>>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe
>

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe

More information about the Delphi mailing list