-1

i have a custom component that at design time can create a child component like this :

constructor TALRectangle.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  fShadow := TalShadow.Create;
  fShadow.OnChanged := ShadowChanged;
end;

procedure TALRectangle.ShadowChanged(Sender: TObject);
begin
  ...
  if shadow.enabled then begin
    fShadowEffect := TshadowEffect.Create(self);
    fShadowEffect.Parent := self;
  end;
  ...
end;

The problem is that I will have after in the dfm/fmx form :

object ALRectangle1: TALRectangle
  shadow.enabled = True
  object TShadowEffect
    Softness = 0.500000000000000000
    Opacity = 1.000000000000000000
    ShadowColor = x96000000
  end
end

but I don't want to anything regarding TShadowEffect in the dfm/fmx form as i create and init this object on the fly.

how to do ?

zeus
  • 12,173
  • 9
  • 63
  • 184
  • 3
    That code cannot possibly put that content in the DFM, because code you write in the editor is only executed at **runtime**, not **designtime**. You can confirm this easily enough; add `fShadowEffect.Softness = 0.25; fShadowEffect.Opacity := 0.01;` to your code and recompile. What do you have in the .dfm now? – Ken White Apr 17 '17 at 16:08
  • thanks ken for helping, but you maybe wrong because TALRectangle is a visual control and ShadowChanged can be fired at design time when we update it's shadow property from the object inspector – zeus Apr 17 '17 at 16:11
  • *when we update it's shadow property from the **Object Inspector*** is correct. But it's not when you say **from code I've written in the Code Editor**, which is what your question says. I assure you that I am **100% certain** that I am not wrong about this. I can also assure you that **you** are **100% wrong** about this. Code you write in the code editor can **never** change what's stored in the .dfm file. – Ken White Apr 17 '17 at 16:12
  • where you see i wrote Code Editor ? – zeus Apr 17 '17 at 16:13
  • You said *when I code like this...I will have after in the dfm/fmx form*. – Ken White Apr 17 '17 at 16:18
  • Clearly you have another problem. It is impossible for what you describe to happen. The runtime of your application has no possible way to access your source files (unless of course you write that feature yourself). – Jerry Dodge Apr 17 '17 at 16:19
  • @JerryDodge: not at runtime; TalRectangle is a visual component (else off course), so it's at design time that the code ShadowChanged is called ! – zeus Apr 17 '17 at 16:23
  • @KenWhite: don't know where i see i wronte "i code like this ...", i say clearly "At design time i ...", – zeus Apr 17 '17 at 16:25
  • Wait, I've misunderstood. Now I'm even more confused. Event handlers defined in the Object Inspector never get fired in design-time. Are you writing a custom control of some sort? How are you running code in design-time otherwise? Now that we're discussing events, it seems you are asking about two different problems... – Jerry Dodge Apr 17 '17 at 16:25
  • @JerryDodge ... oooh i understand where you misunderstood, ShadowChanged it's a property handled internaly. TalRectangle.create; begin fShadow := TalShadow.Create; fShadow.OnChanged := ShadowChanged; end; – zeus Apr 17 '17 at 16:28
  • Yes, in your first sentence you said *At design time I* and then **pasted in code from the CODE EDITOR**, which means **wrote code**. Are you having trouble reading back what you wrote? And then you said ***after, I get this in the dfm/fmx form***, and I said **No, the code you wrote in the Code Editor did not result in **after, I have this in the dfm/fmx form**. – Ken White Apr 17 '17 at 16:31
  • It seems my minunderstanding is that you are actually writing a custom control. All this time I thought you were merely consuming one. Well of course, if you have published properties exposed through the component, yes, it will get saved to DFM. That's the whole purpose of published properties. – Jerry Dodge Apr 17 '17 at 16:33
  • @JerryDodge their is no way to not saved to the dfm ? – zeus Apr 17 '17 at 16:34
  • 1
    I don't know, we can't see the rest of your code, specifically where you have this declared. But it seems you must have it published somehow. Perhaps, even passing an owner / parent to it could be the culprit. I don't have access to my IDE to test at the moment though. – Jerry Dodge Apr 17 '17 at 16:35
  • Hard to know what @Ken means. Of course when you write a custom control in the code editor then it can lead to properties stored in the dfm. – David Heffernan Apr 17 '17 at 17:02
  • @David: No, when you write code in the code editor (even while designing a component), it cannot end up adding properties to the .DFM. It **can**, of course, once you've **compiled, installed and used** that component. But that's not what the question asks. If that was the *intent* of the question, then it should be edited to say so. – Ken White Apr 17 '17 at 17:05
  • Nice battle..... Go on, don't stop. It is entertaining..... :) – Gabriel Sep 05 '17 at 08:57

1 Answers1

10

There are two ways to handle this:

  1. Simply don't create the TShadowEffect object at design-time to begin with:

    procedure TALRectangle.ShadowChanged(Sender: TObject);
    begin
      ...
      if fShadow.Enabled and not (csDesigning in ComponentState) then begin
        fShadowEffect := TShadowEffect.Create(Self);
        fShadowEffect.Parent := Self;
      end;
      ...
    end;
    
  2. if you must create it, then set its Stored property to false:

    procedure TALRectangle.ShadowChanged(Sender: TObject);
    begin
      ...
      if fShadow.Enabled then begin
        fShadowEffect := TShadowEffect.Create(Self);
        fShadowEffect.Parent := Self;
        fShadowEffect.SetSubComponent(True);
        fShadowEffect.Stored := False;
      end;
      ...
    end;
    
Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
  • 2
    @JerryDodge: since forever. It exists in VCL, too, as it is a method of `TComponent`, which VCL and FMX share. If you host a `TComponent` inside of another `TComponent` at design time, you have to call `SetSubComponent(true)` if you want to avoid DFM streaming the inner object. FMX just takes it a step further by adding the `Stored` property, too. – Remy Lebeau Apr 17 '17 at 22:24
  • 1
    Hi Remy. I like how you posted a GOOD and informative answer (and a solution to the problem) without participating in the "let's devour each other" chat the other guys started above. I always find something interesting in your posts! You REALLY make StackOverflow (and Delphi) better! – Gabriel Sep 05 '17 at 08:55