Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/VCL/Core VCL Classes/TFrame    [ Add a report in this area ]  
Report #:  12257   Status: Closed
TabStop property isn't streamed correctly for frames
Project:  Delphi Build #:  9.0.1761.24408
Version:    10.0 Submitted By:   Ulrich Gerhardt
Report Type:  Basic functionality failure Date Reported:  4/25/2005 5:01:12 AM
Severity:    Commonly encountered problem Last Updated: 3/20/2012 2:24:39 AM
Platform:    All platforms Internal Tracking #:   233600
Resolution: Cannot Reproduce (Resolution Comments) Resolved in Build: : 14.0.3567.25216
Duplicate of:  None
Voting and Rating
Overall Rating: (12 Total Ratings)
4.92 out of 5
Total Votes: 21
Description
The TabStop property can't be permanently set to False for frames. If you set TabStop to false for a TFrame descendant in the object inspector, then save, close and reopen the unit, OI will show True for the TabStop property. If you save the unit now, Delphi writes this (wrong) setting out to the corresponding DFM file.
Steps to Reproduce:
- Create a new VCL for Win32 project or open an existing one.
- Add a frame to the project and save it as TestFrame.pas.
- Change the frame's TabStop property to false in the object inspector.
- Save and close TestFrame.pas.
- Reopen TestFrame.pas in the Delphi IDE and switch to form view.
- Object inspector shows True for TabStop.
- Save TestFrame.pas.
- Open TestFrame.dfm in Notepad. It shows the Line "TabStop = True"
Workarounds
Always make sure TabStop is set to False before you save the frame unit.
Attachment
None
Comments

Jeremy Praay at 8/11/2005 7:22:41 AM -
I thought that another possible work-around for this is to set "TabStop := False" at runtime in the Create method of the new frame, but this does not appear to work either.  I had to set it to False in the create event of my form (since it also does not save the frame's TabStop on the form using it).

I'm surprised this hasn't been reported by more people, since it's easily reproducible, and since it is a major headache for the developer trying to figure out why it won't save "TabStop = False" at desgn-time.

Ulrich Gerhardt at 8/12/2005 12:32:42 AM -
Thank you for your comment! It's nice to see that somebody else is interested in this. :-)

Jeremy Praay at 8/30/2005 6:23:11 AM -
Glad to do it.  I hope someone reads this and realizes that this bug nearly makes TFrames unusable for many, if not most, situations.  I can't speak for everyone, but I would almost NEVER want a TabStop on a frame.  Sure, I want it to stop on the controls within the frame, but not on the frame itself.  Additionally, the fact that there is no easy work-around for this (i.e. you can't add "TabStop := False" in the Create of frame) seems like this bug should be investigated/resolved sooner rather than later.

Jeremy Praay at 8/30/2005 9:08:40 AM -
WORKAROUND:
I found this example in a different TFrame bug, and adapted it to work for this as well.

type
  TFrame1 = class(TFrame)
  private
    procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED;
  end;

procedure TFrame1.CMShowingChanged(var M: TMessage);
begin
  inherited;
  TabStop := False;
end;

Jeremy Praay at 9/27/2005 8:07:24 AM -
Is it possible change the severity of this?  

This appears to be a problem with every single application that uses a frame.  It's not "infrequent" unless you never use frames.  If you use frames, it happens every single time, for every single user, in every single application, as far as I can tell.

It doesn't appear that anyone from Borland has even looked at this issue, since there is no internal tracking number.  

This was reported in April, and it still hasn't even been acknowledged.

Ulrich Gerhardt at 9/28/2005 12:53:37 AM -
I changed the severity to "common" because I consider your remarks regarding the impact on frame users correct. However I think one just has to be patient if one uses QC.

Jo Reiter at 8/9/2006 3:59:50 AM -
In my observation this is some kind of IDE problem - not a VCL bug. The problem only occurs, if the project is compiled with the form (containing the frame) opened in the IDE. Otherwise Frame.Tabstop works correctly.

1. Place a frame in a form.
2. Set the Tabstop property to False. (Both in the frame and form.)
3. Set a breakpoint in the Form.OnShow Event.
4. Watch the Tabstop property of the frame.
5. Save the project.
6. Debug the project.  The Frame.Tabstop property is set to True. (Bug!)
7. Now close the form and frame in the IDE and re-open the project.
8. Build and debug the project. Now the Frame.Tabstop property is properly set to False.

WORKAROUND:
- Close all forms and frames in the IDE.
- Re-Open the project.
- Build.

This requires no code changes at all.

Dimitry Timokhov at 8/9/2006 4:16:33 AM -
I also saw this problem.
Finally I started to assign TabStop at runtime :(

Maxim Abramovich at 10/18/2006 9:02:56 AM -
It seems to me that the simplest workaround for the problem will be reintodusing the TabStop property in the frame.

type
  TMyFrame = class(TFrame)
  private
    function GetTabStop: Boolean;
    procedure SetTabStop(const Value: Boolean);
  published
    property TabStop: Boolean read GetTabStop write SetTabStop stored False;
  end;

function TMyFrame.GetTabStop: Boolean;
begin
  Result := inherited TabStop;
end;

procedure TMyFrame.SetTabStop(const Value: Boolean);
begin
  //Do nothing here, just ignore the Value
end;

N.B. This will not solve the problem with IDE. Delphi will still store TabStop=True in dfm files but it will call TMyFrame.SetTabStop method while restoring it from dfm. So we can ignore it.

PS you could also handle CM_TABSTOPCHANGED message to restore valid TabStop value after it was changed but be careful because TabStop changing will generate a new CM_TABSTOPCHANGED message so it will call your message handler recursively.

Thomas Markreiter at 2/8/2007 2:01:09 AM -
I do not understand why this bug is not fixed yet. It's a main functionality which is used by many developers. And there is nothing than a workaround.

We've now implemented the workaround and we've also changed hundreds of LOC's from TFrame to TNewFrame. But the impact now is, that we can not add the derived classes to the tool palette. When we derive a frame-class directly from TFrame (like TMySpecicalFrame = class(TFrame)) we get a menu-item in the context-sensitive menu "add to palette". But when we derive TMySpecialFrame from TNewFrame then there is no menu-item in the context-sensitive menu and thus no possibility to add the construct to the tool palette.

Ulrich Gerhardt at 11/20/2009 2:24:45 AM -
Hooray! As I just discovered this issue seems to have been fixed in D2007. What leaves me puzzled is the resolution: "Cannot reproduce" (not "Fixed") in 14.xxx (i.e. D2010, *not* D2007).

Tomohiro Takahashi at 11/20/2009 6:07:54 PM -
>  ... this issue seems to have been fixed in D2007 ...
Thanks for the confirmation. I will check the internal status.

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.