#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2002
    Posts
    86
    Rep Power
    13

    Form.Activate ShowModal form stops pagecontrol anchoring


    I have a form that opens in Modal mode on .activate, I need the user to enter some info before moving on to the main app.

    Problem is that the application maximizes as needed but a page control within the app does not "anchor" on the maximize... in other words it's smaller in the main form itself even after closing the modal form.

    It does re size (fit/anchor) after changing to another tab and come back to the original opening tab.

    Of course I would like everything to be drawn properly before opening the Modal form, is there a way to do that?

    Thank you

    Greg.
    Last edited by dlumley; June 29th, 2012 at 07:38 AM.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jan 2006
    Location
    Carlsbad, CA
    Posts
    2,057
    Rep Power
    383
    Don't open a another form in the onActivate event (or onCreate or onShow) you are setting up a conflict right there.
    Move the code to a timer.
    In onActivate set the timer.enabled to True.
    in onTimer first set timer.enabled to false then add your code.

    Clive
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2012
    Posts
    156
    Rep Power
    3
    Instead of using timer, which overhead is too big for this simple task, you can just define a custom message, post this message to the main form in OnShow, and in the message's handler you show the modal form.

    I recommend the OnShow event for this event will raised after the form properly shown after hidden.

    Something like this:

    Code:
    uses
      ..., Messages, ..;
    
    const
      MSG_SHOWTHEMODAL = WM_USER + 111;
    ...
    type
      TFrmMain=class(TForm)
      ...
        procedure FormShow(Sender: TObject);
      private
        procedure HandleShowTheModal(var AMsg); message MSG_SHOWTHEMODAL;
        ...
      end;
    
    implementation
      ...
    procedure TFrmMain.FormShow(Sender: TObject);
    begin
      ...
      Self.OnShow := nil; // so this event handler only called once
      PostMessage(Self.Handle, MSG_SHOWTHEMODAL, 0, 0);
      ...
    end;
    
    procedure TFrmMain.HandleShowTheModal(var AMsg);
    begin
      with TMyModalForm.Create(Self) do
      try
        ...
        if ShowModal=mrOk then
          ...
        ...
      finally
      end;
    end;
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jan 2006
    Location
    Carlsbad, CA
    Posts
    2,057
    Rep Power
    383
    Instead of using timer, which overhead is too big for this simple task,
    Of all the reasons you might choose to object to using a timer, this must be about the last.

    I feel compelled to respond, not to point out that you are mistaken but just to make sure
    no beginner gets the wrong idea about a timer having any meaningful overhead in this situation.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2012
    Posts
    156
    Rep Power
    3
    Originally Posted by clivew
    Of all the reasons you might choose to object to using a timer, this must be about the last.

    I feel compelled to respond, not to point out that you are mistaken but just to make sure
    no beginner gets the wrong idea about a timer having any meaningful overhead in this situation.
    You definitely not know the inside of a TTimer.

    1. Enabling TTimer will create a window handle. The process of creating a window handle is another overhead, isn't it?
    2. Window handle itself is window resource. Which is recommended not to be abused. So, another overhead, isn't it?
    3. If you decide to create the TTimer in design time, it will be added to dfm. Any published properties of the TTimer will be added to the form's dfm, which will increase the exe size. Another overhead, right?
    4. If you decide to add TTimer in design time, it will put it into Components collection of the form. Another waste of memory, right?
    5. Upon disabling the TTimer, the internal window handle will also need to be destroyed. Wasting cpu cycle and space to contain the codes to do it. Isn't it also overhead?


    It's up to you to ignore these overhead if you want. I simply offer perfectly elegant solution without these many overhead.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jan 2006
    Location
    Carlsbad, CA
    Posts
    2,057
    Rep Power
    383
    You definitely not know the inside of a TTimer.
    I am impressed by your intimate insight into the breadth of my knowledge!

    The points you make are totally irrelevant with a modern cpu with a modern O/S.

    Te application will contain a myriad of windows handles and resources and will be
    creating and destroying them all the time.
    Your points may have been relevant a quarter century ago and with 16-bit Windows.
    Not today.
    If you are going to object to something as lightweight as a TTimer component that fires just once
    you had better throw out the entire visual programming paradigm.

    Clive
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2012
    Posts
    156
    Rep Power
    3
    Instead of whining, and shifting the subject from what you have brought it yourself, why don't you just answer my questions in my reply?

    Let me put it simple, just answer this question:

    AREN'T THEY ALL OVERHEADS THAT DO NOT EXIST IN MY SOLUTION?

    Thank you very much.

    P.S. Sorry that I used all capitals. It just seems that you can not put straight answers to simple questions.

    Originally Posted by clivew
    I am impressed by your intimate insight into the breadth of my knowledge!

    The points you make are totally irrelevant with a modern cpu with a modern O/S.

    Te application will contain a myriad of windows handles and resources and will be
    creating and destroying them all the time.
    Your points may have been relevant a quarter century ago and with 16-bit Windows.
    Not today.
    If you are going to object to something as lightweight as a TTimer component that fires just once
    you had better throw out the entire visual programming paradigm.

    Clive
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Jan 2006
    Location
    Carlsbad, CA
    Posts
    2,057
    Rep Power
    383
    I am not continuing this discussion.
    Anyone reading this thread has enough information to form their own opinion.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2012
    Posts
    156
    Rep Power
    3
    Originally Posted by clivew
    I am not continuing this discussion.
    Anyone reading this thread has enough information to form their own opinion.
    No problem with me. Although their first opinion would be that you can not give straight answer for simple question if the answer did not satisfy your ego.

IMN logo majestic logo threadwatch logo seochat tools logo