The Shed is going Social! Join us on FaceBook and Twitter and chime in on the conversation.
|
 |
|
Dev Shed Forums
> Programming Languages - More
> Delphi Programming
|
How to open a form after the application has loaded...
Discuss How to open a form after the application has loaded... in the Delphi Programming forum on Dev Shed. How to open a form after the application has loaded... Delphi Programming forum discussing Delphi related topics including Kylix, C++ Builder, and more. Delphi is a high-performance language, originally based on the PASCAL language.
|
|
 |
|
|
|
|

Dev Shed Forums Sponsor:
|
|
|

June 29th, 2012, 05:20 AM
|
|
Contributing User
|
|
Join Date: May 2002
Posts: 86
Time spent in forums: 7 h 29 m 26 sec
Reputation Power: 12
|
|
|
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.
|

June 29th, 2012, 10:46 AM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
|
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
|

July 4th, 2012, 12:01 AM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 141
Time spent in forums: 1 Day 5 h 1 m 56 sec
Reputation Power: 2
|
|
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;
|

July 4th, 2012, 12:41 AM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
Quote: | 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.
|

July 4th, 2012, 01:03 AM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 141
Time spent in forums: 1 Day 5 h 1 m 56 sec
Reputation Power: 2
|
|
Quote: | 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. - Enabling TTimer will create a window handle. The process of creating a window handle is another overhead, isn't it?
- Window handle itself is window resource. Which is recommended not to be abused. So, another overhead, isn't it?
- 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?
- If you decide to add TTimer in design time, it will put it into Components collection of the form. Another waste of memory, right?
- 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.
|

July 4th, 2012, 11:24 AM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
Quote: | 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
|

July 4th, 2012, 11:39 AM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 141
Time spent in forums: 1 Day 5 h 1 m 56 sec
Reputation Power: 2
|
|
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.
Quote: | 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 |
|

July 4th, 2012, 12:28 PM
|
|
Contributing User
|
|
Join Date: Jan 2006
Location: Carlsbad, CA
|
|
|
I am not continuing this discussion.
Anyone reading this thread has enough information to form their own opinion.
|

July 4th, 2012, 12:39 PM
|
|
Contributing User
|
|
Join Date: May 2012
Posts: 141
Time spent in forums: 1 Day 5 h 1 m 56 sec
Reputation Power: 2
|
|
Quote: | 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.
|
Developer Shed Advertisers and Affiliates
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|